Loading ...
Sorry, an error occurred while loading the content.
 

International email addresses (RFC 6531)

Expand Messages
  • Freek Dijkstra
    Hi all, Postfix does not support international email addresses, such as josé@example.org, as described by RFC 6530-6532. To be precise, the SMPTUTF8
    Message 1 of 19 , Dec 29, 2013
      Hi all,

      Postfix does not support international email addresses, such as
      josé@..., as described by RFC 6530-6532. To be precise, the
      SMPTUTF8 (previously: UTF8SMTP) SMTP extension is not announced in the
      EHLO response.

      Wikipedia [1] says it is "under development", but given the response to
      the topic "Question about supporting EAI in postfix" about a year ago
      [2] I get the impression it is not.

      Would anybody be aware of external contributions to Postfix for this
      feature? I have not found anything on the web.

      Regards,
      Freek

      [1] https://en.wikipedia.org/wiki/Extended_SMTP#SMTPUTF8
      [2] http://thread.gmane.org/gmane.mail.postfix.user/234284/focus=234286
    • lists@rhsoft.net
      ... and even if postfix supports it you gain nothing for a lot of reasons * not everybody is using postfix * not everybody using postfix is using the latest
      Message 2 of 19 , Dec 29, 2013
        Am 29.12.2013 14:13, schrieb Freek Dijkstra:
        > Postfix does not support international email addresses, such as
        > josé@..., as described by RFC 6530-6532. To be precise, the
        > SMPTUTF8 (previously: UTF8SMTP) SMTP extension is not announced in the
        > EHLO response.
        >
        > Wikipedia [1] says it is "under development", but given the response to
        > the topic "Question about supporting EAI in postfix" about a year ago
        > [2] I get the impression it is not.
        >
        > Would anybody be aware of external contributions to Postfix for this
        > feature? I have not found anything on the web.
        >
        > [1] https://en.wikipedia.org/wiki/Extended_SMTP#SMTPUTF8
        > [2] http://thread.gmane.org/gmane.mail.postfix.user/234284/focus=234286

        and even if postfix supports it you gain nothing for a lot of reasons

        * not everybody is using postfix
        * not everybody using postfix is using the latest version
        * not all other mailservers supports it
        * no all other software verify addresses and filter mails supports it
        * any *involved* machine from sender to final RCPT need to support it 100%

        hence forget this broken idea for the next at least 5 years
      • Wietse Venema
        ... With RFC 6530 an SMPTUTF8-capable MTA can t forward email with an SMPTUTF8 sender address to a non-SMPTUTF8 MTA. It must return such email as
        Message 3 of 19 , Dec 29, 2013
          Freek Dijkstra:
          > Hi all,
          >
          > Postfix does not support international email addresses, such as
          > jos?@..., as described by RFC 6530-6532. To be precise, the
          > SMPTUTF8 (previously: UTF8SMTP) SMTP extension is not announced in the
          > EHLO response.
          >
          > Wikipedia [1] says it is "under development", but given the response to
          > the topic "Question about supporting EAI in postfix" about a year ago
          > [2] I get the impression it is not.
          >
          > Would anybody be aware of external contributions to Postfix for this
          > feature? I have not found anything on the web.

          With RFC 6530 an SMPTUTF8-capable MTA can't forward email with an
          SMPTUTF8 sender address to a non-SMPTUTF8 MTA. It must return such
          email as undeliverable. See sections 8 and 9.

          In other words, email with your "international" sender address will
          be undeliverable to vast portions of the Internet. Is that what you
          want?

          And that is just one problem with SMPTUTF8.

          Earlier Internet email extensions such as MIME were careful to
          maintain interoperability with existing infrastructure, providing
          a path for gradual migration from the present to the future.

          UTF8SMTP tried to provide a path for gradual migration but failed.
          SMPTUTF8 provides no migration path as noted above - it returns
          mail as undeliverable. Without a path for gradual migration towards
          internationalized email, I expect that SMPTUTF8 will fail, too.

          Wietse
        • Andrzej A. Filip
          ... So SMPTUTF8 clients should be capable to set/choose traditional or internationalized sender address per recipient and split sending of multi-reipient
          Message 4 of 19 , Dec 29, 2013
            On 12/29/2013 05:51 PM, Wietse Venema wrote:
            > Freek Dijkstra:
            >> Hi all,
            >>
            >> Postfix does not support international email addresses, such as
            >> jos?@..., as described by RFC 6530-6532. To be precise, the
            >> SMPTUTF8 (previously: UTF8SMTP) SMTP extension is not announced in the
            >> EHLO response.
            >>
            >> Wikipedia [1] says it is "under development", but given the response to
            >> the topic "Question about supporting EAI in postfix" about a year ago
            >> [2] I get the impression it is not.
            >>
            >> Would anybody be aware of external contributions to Postfix for this
            >> feature? I have not found anything on the web.
            >
            > With RFC 6530 an SMPTUTF8-capable MTA can't forward email with an
            > SMPTUTF8 sender address to a non-SMPTUTF8 MTA. It must return such
            > email as undeliverable. See sections 8 and 9.
            >
            > In other words, email with your "international" sender address will
            > be undeliverable to vast portions of the Internet. Is that what you
            > want?
            >
            > And that is just one problem with SMPTUTF8.
            >
            > Earlier Internet email extensions such as MIME were careful to
            > maintain interoperability with existing infrastructure, providing
            > a path for gradual migration from the present to the future.
            >
            > UTF8SMTP tried to provide a path for gradual migration but failed.
            > SMPTUTF8 provides no migration path as noted above - it returns
            > mail as undeliverable. Without a path for gradual migration towards
            > internationalized email, I expect that SMPTUTF8 will fail, too.

            So SMPTUTF8 clients should be capable to set/choose traditional or
            internationalized sender address per recipient and split sending of
            multi-reipient messages?

            "where there's a will there's a way"

            I share your opinion that english speaking parts of Internet will be
            slow to mass support SMTPUTF8. As native speaker of another language I
            do not see it as a very important obstacle.
          • lists@rhsoft.net
            ... it s hard to say how to handle this in a sane way that s why for interoperability the idea of special chars should be avoided ... i fail how it could be
            Message 5 of 19 , Dec 29, 2013
              Am 29.12.2013 20:23, schrieb Andrzej A. Filip:
              > On 12/29/2013 05:51 PM, Wietse Venema wrote:
              >> UTF8SMTP tried to provide a path for gradual migration but failed.
              >> SMPTUTF8 provides no migration path as noted above - it returns
              >> mail as undeliverable. Without a path for gradual migration towards
              >> internationalized email, I expect that SMPTUTF8 will fail, too.
              >
              > So SMPTUTF8 clients should be capable to set/choose traditional or
              > internationalized sender address per recipient and split sending of
              > multi-reipient messages?

              it's hard to say how to handle this in a sane way
              that's why for interoperability the idea of special chars should be avoided

              > "where there's a will there's a way"
              >
              > I share your opinion that english speaking parts of Internet will be
              > slow to mass support SMTPUTF8. As native speaker of another language I
              > do not see it as a very important obstacle

              i fail how it could be helpful for anybody if as example his own
              MTA accepts the address and the last hop for the final destination
              rejects it - and that is what will happen for many many years if
              not virtually forever because there are *a lot* of legacy systems
              and that hardly will change in the near future

              so even if *any* SMTP software would support RFC 6531 in the last
              recent version this will not change the fact that as example the
              next RHEL7 in 2014 will be supported for *10 years* with only
              security updates and no functional changes

              forget it
            • lst_hoe02@...
              ... IMHO The e-Mail address is just a routeable name. For your real name in whatever charset you should use the real name in the header section. Regards
              Message 6 of 19 , Dec 29, 2013
                Zitat von Freek Dijkstra <public@...>:

                > Hi all,
                >
                > Postfix does not support international email addresses, such as
                > josé@..., as described by RFC 6530-6532. To be precise, the
                > SMPTUTF8 (previously: UTF8SMTP) SMTP extension is not announced in the
                > EHLO response.
                >
                > Wikipedia [1] says it is "under development", but given the response to
                > the topic "Question about supporting EAI in postfix" about a year ago
                > [2] I get the impression it is not.
                >
                > Would anybody be aware of external contributions to Postfix for this
                > feature? I have not found anything on the web.
                >
                > Regards,
                > Freek
                >
                > [1] https://en.wikipedia.org/wiki/Extended_SMTP#SMTPUTF8
                > [2] http://thread.gmane.org/gmane.mail.postfix.user/234284/focus=234286

                IMHO The e-Mail address is just a "routeable" name. For your real name
                in whatever charset you should use the real name in the header section.

                Regards

                Andreas
              • Wietse Venema
                ... Try to explain to your parents that they sent email in the wrong format, and now they have to send it again in a different format. They will just stop
                Message 7 of 19 , Dec 29, 2013
                  Andrzej A. Filip:
                  > > UTF8SMTP tried to provide a path for gradual migration but failed.
                  > > SMPTUTF8 provides no migration path as noted above - it returns
                  > > mail as undeliverable. Without a path for gradual migration towards
                  > > internationalized email, I expect that SMPTUTF8 will fail, too.
                  >
                  > So SMPTUTF8 clients should be capable to set/choose traditional or
                  > internationalized sender address per recipient and split sending of
                  > multi-reipient messages?
                  >
                  > "where there's a will there's a way"

                  Try to explain to your parents that they sent email in the wrong
                  format, and now they have to send it again in a different format.

                  They will just stop using email and do their correspondence on a
                  properietary platform (facebook, and the like).

                  Wietse
                • Freek Dijkstra
                  Hi Wietse, et al., Thank you for your explanation. I now understand that you do not have any plans on supporting this feature due to interoperability concerns.
                  Message 8 of 19 , Dec 29, 2013
                    Hi Wietse, et al.,

                    Thank you for your explanation. I now understand that you do not have
                    any plans on supporting this feature due to interoperability concerns.

                    Would you be willing to accept external patches to add RFC 6531
                    functionality?

                    (Admittedly, this is a bit of an academic question -- I'm starting to
                    see some IDNs in email, and wanted to find out the status of
                    international email addresses in general. I now have that answer.)


                    I didn't intent to start a discussion if RFC 6531 is good or bad, but
                    now that we have that discussion, here are my two cents.

                    While I perfectly understand that other features are more important to
                    implement, I'm a bit surprised by the rather strong opinion voiced on
                    this list against this feature. Personally, I rather see UTF-8 encoded
                    mail headers than HTML-encoded mail bodies. ;).

                    > In other words, email with your "international" sender address will
                    > be undeliverable to vast portions of the Internet. Is that what you
                    > want?

                    Personally, I wouldn't recommend anyone to start creating email
                    addresses with non-ASCII characters in the local part (the domain name
                    part is fine), precisely for the incompatibility reasons you cite.

                    However, on the off-chance that someone else creates such mail
                    addresses, now that it is a IETF proposed standard (as opposed to RFC
                    5336, which was 'only' experimental), I would hate to see that Postfix,
                    my favorite MTA, would be the one that causes the bounce because it is
                    incapable of handling such address.

                    Regards,
                    Freek
                  • Wietse Venema
                    ... That understanding is not necessarily correct. I hope that some clever person will come up with a tweak to the proposed protocols that avoids the need to
                    Message 9 of 19 , Dec 29, 2013
                      Freek Dijkstra:
                      > Hi Wietse, et al.,
                      >
                      > Thank you for your explanation. I now understand that you do not have
                      > any plans on supporting this feature due to interoperability concerns.

                      That understanding is not necessarily correct. I hope that some
                      clever person will come up with a tweak to the proposed protocols
                      that avoids the need to bounce email with a non-ASCII sender (or
                      non-ASCII whatever).

                      > Would you be willing to accept external patches to add RFC 6531
                      > functionality?

                      RFC 6531 is about announcing SMTPUTF8 support in SMTP. That
                      is 1% of all the work that is needed to implement SMTPUTF8.

                      In order to announce SMTPUTF8 support, the other 99% must be done
                      first. To correctly processes SMTPUTF8 requires changes to address
                      manipulation, MIME support, delivery status notifications, delivery
                      agents (can't just blindly pass UTF8 into shell command lines),
                      and returning mail as undeliverable when the next MTA does not
                      announce SMTPUTF8 support.

                      The way I read your proposal is that Postfix would only pretend
                      that it supports SMTPUTF8, without doing the 99% of the work.

                      Wietse
                    • Freek Dijkstra
                      ... RFC 6530 sect 8 seems to suggest that RFC 2047 (MIME Message Header Extensions for Non-ASCII Text) could be used, but that is only mentioned as one
                      Message 10 of 19 , Dec 29, 2013
                        On 29-12-2013 22:51, Wietse Venema wrote:

                        > I hope that some
                        > clever person will come up with a tweak to the proposed protocols
                        > that avoids the need to bounce email with a non-ASCII sender (or
                        > non-ASCII whatever).

                        RFC 6530 sect 8 seems to suggest that RFC 2047 (MIME Message Header
                        Extensions for Non-ASCII Text) could be used, but that is only mentioned
                        as one possibility.

                        I fear I won't be that clever person. I'm still struggling to understand
                        these four RFCs.

                        > The way I read your proposal is that Postfix would only pretend
                        > that it supporMts SMTPUTF8, without doing the 99% of the work.

                        That would of course be ludicrous, and it never occurred to me that my
                        original email could be interpreted that way. I apologize for the confusion.

                        FYI, I did test a international email in the virtual alias map on a
                        production machine (running a rather old Postfix 2.7.1). It arrived
                        without problems. The spam filter balked at the non-conformant mail
                        headers, but that was all. I was very impressed.

                        I understand that this functionality is just a tip of the iceberg. I had
                        thought about how this effectively changes the API interface to other
                        mail components (such as spam filters, or procmail-like delivery tools)
                        which may now expect ASCII-encoded input. Your list is clearly a lot
                        longer than that.

                        Freek
                      • Wietse Venema
                        ... Indeed. SMTPUTF8 support involves more than the 1% that says I can do SMTPUTF8 in the EHLO handshake. There is a whole list of RFCs that need to be
                        Message 11 of 19 , Dec 29, 2013
                          Freek Dijkstra:
                          > > The way I read your proposal is that Postfix would only pretend
                          > > that it supporMts SMTPUTF8, without doing the 99% of the work.
                          >
                          > That would of course be ludicrous, and it never occurred to me that my
                          > original email could be interpreted that way. I apologize for the confusion.
                          ...
                          > I understand that this functionality is just a tip of the iceberg. I had
                          > thought about how this effectively changes the API interface to other
                          > mail components (such as spam filters, or procmail-like delivery tools)
                          > which may now expect ASCII-encoded input. Your list is clearly a lot
                          > longer than that.

                          Indeed. SMTPUTF8 support involves more than the 1% that says "I can
                          do SMTPUTF8" in the EHLO handshake. There is a whole list of RFCs
                          that need to be supported first.

                          Wietse
                        • Viktor Dukhovni
                          ... I think the RFCs in question are a mistake. A far simpler and cleaner design would have been to extend Punycode to the local part of the address. For
                          Message 12 of 19 , Dec 29, 2013
                            On Sun, Dec 29, 2013 at 10:09:12PM -0500, Wietse Venema wrote:

                            > Indeed. SMTPUTF8 support involves more than the 1% that says "I can
                            > do SMTPUTF8" in the EHLO handshake. There is a whole list of RFCs
                            > that need to be supported first.

                            I think the RFCs in question are a mistake. A far simpler and
                            cleaner design would have been to extend Punycode to the local part
                            of the address. For some reason the IETF working group did not
                            choose the approach with the simplest migration path. There are
                            other IETF RFCs that never get much adoption, I hope and expect
                            that these will be among them.

                            --
                            Viktor.
                          • Andrzej A. Filip
                            ... IMHO Extending punycode to local part may be a good option for mostly ASCII charsets (ISO-8859-X) but it may create (too) long names for completely non
                            Message 13 of 19 , Dec 30, 2013
                              On 12/30/2013 04:55 AM, Viktor Dukhovni wrote:
                              > On Sun, Dec 29, 2013 at 10:09:12PM -0500, Wietse Venema wrote:
                              >
                              >> Indeed. SMTPUTF8 support involves more than the 1% that says "I can
                              >> do SMTPUTF8" in the EHLO handshake. There is a whole list of RFCs
                              >> that need to be supported first.
                              >
                              > I think the RFCs in question are a mistake. A far simpler and
                              > cleaner design would have been to extend Punycode to the local part
                              > of the address. For some reason the IETF working group did not
                              > choose the approach with the simplest migration path. There are
                              > other IETF RFCs that never get much adoption, I hope and expect
                              > that these will be among them.

                              IMHO Extending punycode to local part may be a good option for "mostly
                              ASCII" charsets (ISO-8859-X) but it may create (too) long names for
                              "completely non ASCII charsets".

                              There is as always conflict between short term ease of transition and
                              long term simplicity.
                            • Luigi Rosa
                              ... Hash: SHA1 ... Agreed. Why not use the same algorithm used by IDNA (RFC3490)? There are already an adopted RFC and a working algorithm, why reinvent the
                              Message 14 of 19 , Dec 30, 2013
                                -----BEGIN PGP SIGNED MESSAGE-----
                                Hash: SHA1

                                Viktor Dukhovni said the following on 30/12/2013 04:55:

                                >> Indeed. SMTPUTF8 support involves more than the 1% that says "I can do
                                >> SMTPUTF8" in the EHLO handshake. There is a whole list of RFCs that need
                                >> to be supported first.
                                >
                                > I think the RFCs in question are a mistake. A far simpler and cleaner
                                > design would have been to extend Punycode to the local part of the address.
                                >
                                Agreed.
                                Why not use the same algorithm used by IDNA (RFC3490)? There are already an
                                adopted RFC and a working algorithm, why reinvent the wheel?

                                Otherwise we could end up with an email address whit a local part encoded with
                                algorithm A and a domain name encoded with algorithm B.


                                Ciao,
                                luigi

                                - --
                                /
                                +--[Luigi Rosa]--
                                \

                                Law of the Perversity of Nature: You cannot successfully determine
                                beforehand which side of the bread to butter.
                                -----BEGIN PGP SIGNATURE-----
                                Version: GnuPG v1.4.14 (GNU/Linux)
                                Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

                                iEYEARECAAYFAlLBLgYACgkQ3kWu7Tfl6ZSNhwCeMBQLUYSF3+mtCqkOFMddo87Y
                                a8EAoLhlakYzz1Epxb1RiPlE0caQ9o/z
                                =0air
                                -----END PGP SIGNATURE-----
                              • Andreas Kasenides
                                ... My opinion (slightly off topic but very relevant) having read the thread carefully: It is obvious that the English speaking world does not want to abandon
                                Message 15 of 19 , Dec 30, 2013
                                  On 29-12-2013 22:05, lst_hoe02@... wrote:
                                  > Zitat von Freek Dijkstra <public@...>:
                                  >
                                  >> Hi all,
                                  >>
                                  >> Postfix does not support international email addresses, such as
                                  >> josé@..., as described by RFC 6530-6532. To be precise, the
                                  >> SMPTUTF8 (previously: UTF8SMTP) SMTP extension is not announced in the
                                  >> EHLO response.
                                  >>
                                  >> Wikipedia [1] says it is "under development", but given the response
                                  >> to
                                  >> the topic "Question about supporting EAI in postfix" about a year ago
                                  >> [2] I get the impression it is not.
                                  >>
                                  >> Would anybody be aware of external contributions to Postfix for this
                                  >> feature? I have not found anything on the web.
                                  >>
                                  >> Regards,
                                  >> Freek
                                  >>
                                  >> [1] https://en.wikipedia.org/wiki/Extended_SMTP#SMTPUTF8
                                  >> [2]
                                  >> http://thread.gmane.org/gmane.mail.postfix.user/234284/focus=234286
                                  >
                                  > IMHO The e-Mail address is just a "routeable" name. For your real name
                                  > in whatever charset you should use the real name in the header
                                  > section.
                                  >
                                  > Regards
                                  >
                                  > Andreas


                                  My opinion (slightly off topic but very relevant) having read the thread
                                  carefully:

                                  It is obvious that the English speaking world does not want to abandon
                                  ASCII. For their own reasons.
                                  If you want an RFC (or any project for that matter) to fail then create
                                  an impossible situation
                                  ie no path from the existing status-quo to the new system. The arguments
                                  put forward, by some, are exactly
                                  the same for IPv6. But then the path from IPv4 to IPv6 is well charted
                                  out and understood. Software
                                  have been built long ago when nobody was using IPv6. Incompatibilities
                                  corrected and applications and or
                                  drivers created for several generation now. Still IPv6 is not that
                                  common.

                                  Come to think of it, why don't we go back to using inches, yards, miles
                                  and pounds?
                                  It was, and still is, quite painful converting to SI.

                                  Andreas
                                • Wietse Venema
                                  ... This transformation would be needed only when sending mail between systems that don t support non-ASCII addresses. Just like MIME 8-7bit conversion, the
                                  Message 16 of 19 , Dec 30, 2013
                                    Andrzej A. Filip:
                                    > On 12/30/2013 04:55 AM, Viktor Dukhovni wrote:
                                    > > On Sun, Dec 29, 2013 at 10:09:12PM -0500, Wietse Venema wrote:
                                    > >
                                    > >> Indeed. SMTPUTF8 support involves more than the 1% that says "I can
                                    > >> do SMTPUTF8" in the EHLO handshake. There is a whole list of RFCs
                                    > >> that need to be supported first.
                                    > >
                                    > > I think the RFCs in question are a mistake. A far simpler and
                                    > > cleaner design would have been to extend Punycode to the local part
                                    > > of the address. For some reason the IETF working group did not
                                    > > choose the approach with the simplest migration path. There are
                                    > > other IETF RFCs that never get much adoption, I hope and expect
                                    > > that these will be among them.
                                    >
                                    > IMHO Extending punycode to local part may be a good option for "mostly
                                    > ASCII" charsets (ISO-8859-X) but it may create (too) long names for
                                    > "completely non ASCII charsets".

                                    This transformation would be needed only when sending mail between
                                    systems that don't support non-ASCII addresses. Just like MIME
                                    8-7bit conversion, the need for it goes away over time.

                                    Wietse
                                  • Wietse Venema
                                    ... If there is no migration path that allows different systems to interoperate while the transition is being made, then real people will switch from email to
                                    Message 17 of 19 , Dec 30, 2013
                                      Andreas Kasenides:
                                      > Come to think of it, why don't we go back to using inches, yards,
                                      > miles and pounds? It was, and still is, quite painful converting
                                      > to SI.

                                      If there is no migration path that allows different systems to
                                      interoperate while the transition is being made, then real people
                                      will switch from email to proprietary systems such as FB and the
                                      like, and make the job easier for spying agencies.

                                      Wietse
                                    • Viktor Dukhovni
                                      ... Punycode is a rather efficient encoding. There is little reason to be concerned about the length of the localpart. A more complex issue with Punycode is
                                      Message 18 of 19 , Dec 30, 2013
                                        On Mon, Dec 30, 2013 at 07:10:26AM -0500, Wietse Venema wrote:

                                        > > IMHO Extending punycode to local part may be a good option for "mostly
                                        > > ASCII" charsets (ISO-8859-X) but it may create (too) long names for
                                        > > "completely non ASCII charsets".

                                        Punycode is a rather efficient encoding. There is little reason
                                        to be concerned about the length of the localpart.

                                        A more complex issue with Punycode is that address extensions are
                                        problematic. That said, address extensions are generated by the sender.
                                        Provided the sender's system understands whatever form they take
                                        when the sender's address requires encoding from UTF-8, the rest of
                                        the world need not know or care about how that's accomplished at
                                        each site.

                                        Thus, Postfix would hypothetically need to be able decode from
                                        Punycode to UTF-8, strip the extension, and re-encode when performing
                                        address lookups without the extension in various databases.
                                        Likewise, when generating VERP sender addresses, it would need to
                                        decode, append the extension then re-encode.

                                        IMAP servers that support extensions and also UTF-8 localparts
                                        would need similar logic.

                                        Finally, for human-readable bounces, one might want to include
                                        both the Punycode and the UTF-8 form of the address in bounce
                                        body text.

                                        None of the above would be a major obstacle, or introduce
                                        interoperability issues with remote systems.

                                        > This transformation would be needed only when sending mail between
                                        > systems that don't support non-ASCII addresses. Just like MIME
                                        > 8-7bit conversion, the need for it goes away over time.

                                        There are further complications. To transition to native UTF-8
                                        encoding one needs to modify LDAP schemas, X.509 extension encoding
                                        rules, SQL database character encoding rules, ... I expect the
                                        Punycode localpart form would stay on the wire indefinitely, but
                                        this is not a problem.

                                        There would be a benefit to long-term Punycode localpart addresses.
                                        Message recipients not familiar with the sender's native script
                                        will generally be able distinguish distinct Punycode strings, and
                                        will be able to begin to type the address into their email client
                                        allowing the software to complete it, ...

                                        --
                                        Viktor.
                                      • Wietse Venema
                                        ... I don t think that crutches like this should be deployed in eternity. What we need is a legitimate transformation that allows mail to flow between MTAs
                                        Message 19 of 19 , Dec 30, 2013
                                          Wietse:
                                          > This transformation would be needed only when sending mail between
                                          > systems that don't support non-ASCII addresses. Just like MIME
                                          > 8-7bit conversion, the need for it goes away over time.

                                          Viktor Dukhovni:
                                          > There would be a benefit to long-term Punycode localpart addresses.

                                          I don't think that crutches like this should be deployed in eternity.

                                          What we need is a legitimate transformation that allows mail to
                                          flow between MTAs with and without standardized UTF8 support. Once
                                          enough systems support standardized UTF8, the crutches can go away.
                                          We need the transformation only to enable an orderly transition.

                                          An example of this is the MIME 8bit-to-7bit transformation. It
                                          took care of differences between MTAs without bothering users.
                                          By now, all relevant MTAs are 8-bit clean.

                                          If we can do no better than telling users "you need to resend your
                                          UTF8 email in a different format" then I find that appalling.
                                          Systems should take care of such details. If they don't, then users
                                          will switch to something else.

                                          Wietse
                                        Your message has been successfully submitted and would be delivered to recipients shortly.