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.
