--On 15. mars 2002 20:56 +0000 "D. J. Bernstein"
<djb(_at_)cr(_dot_)yp(_dot_)to> wrote:
Under the IDNA deployment plan, names in the IDNA character encoding
will start showing up in subscription lists immediately. Those names
will be displayed as gobbledygook. The ezmlm-list author will be forced
to have ezmlm-list convert addresses to the local character encoding.
However, if ezmlm-list converts from the IDNA character encoding to the
local character encoding, then the script shown above will break. Mail
will bounce. That's an interoperability disaster.
under the scenario dan presents:
1) upgrading the qmail-inject program to support encoding will do no harm.
Anything that will be changed by encoding was an illegal email address
under the old rules.
2) upgrading both ezmlm-list and qmail-inject does no harm in the scenario
given.
thus, I think the defensive behaviour for ezmlm-list is to implement a
switch:
ezmlm-list
--yes-I-have-really-upgraded-the-thing-that-will-read-this-to-understand-em
ail-addresses-with-utf-8-characters-in-them
given that in the endgame of essentially all programs being upgraded to
undestand UTF-8 email addresses, this switch will be a bother, it should
probably be capable of being specified in a configuration file, so that it
can be left on and negated when needed.
3) contrary to some beliefs, watching gobbledygook is not known to cause
permanent damage in human beings. So not upgrading anything does not cause
much harm either.
4) yes, I do agree that specifying this level of behaviour is out of scope
for the IETF.
Harald