By now it will be clear to everyone that SMTPUTF8 involves more
than changes in the syntax of SMTP commands and bounce message
attributes. That is not the most difficult part. The most difficult
part is how humans will manage Postfix.

Pretty much all Postfix lookup table interfaces will be affected
in some way or another. The same domain name can be in UTF-8 or
xn--mumble form depending on whether it is the client hostname, the
EHLO command parameter, or whether it appears in an envelope email
address.  Logfile analysis will be affected, too.

Multiple forms for the same domain name complicate logfile analysis
and lookup table management. No-one wants to specify multiple forms
of the same domain name in an access table, policy table, or address
rewriting/routing table.  Tables should use one form if possible.

Regardless of what form Postfix lookup tables and logfiles use
internally, I expect that many Postfix tools will need an option
to accept or display domain names as UTF-8 or xn--mumble just so
that human operators can effectively manage Postfix lookup tables,
mailq output, logging, and so on, with domain names in scripts other
than Latin.

Considering the complexity of the human interface aspects, I expect
that SMTPUTF8 will be "experimental" for more than one development
cycle, because it may take several incompatible changes to get
things right. Thus, I stick with my original estimate that SMTPUTF8
will take a few years to implement.

        Wietse

Reply via email to