https://bugs.exim.org/show_bug.cgi?id=1737
John Klensin <john-ietf@???> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |john-ietf@???
--- Comment #1 from John Klensin <john-ietf@???> ---
Personal opinion from someone with some history in this area: I'd discourage
this change.
First of all, unless you can somehow guarantee that all of the recipient-users
and all of their sender-correspondents for a given installation are using the
same language and charset, the trends in the Internet are such that you should
basically get over anything but UTF-8 (including its ASCII subset). I think
doing that gradually is plausible if you have already-deployed applications,
but basing anything new on any local 8bit CCS, including "latin1" (itself
somewhat ambiguous) will just lead to conversion problems later on.
Second, as others have pointed out, one can treat different parts of a
non-delivery (or delivery) notification separately because restrictions in some
body parts don't apply to others. However, taking advantage of that will
inevitably involve tradeoffs between better messages for some users, confusion
for others, and complaints about what is and is not being done that mail system
operators probably don't need. ASCII may be the encoding that everyone who is
concerned about i18n/l12n issues loves to hate -- even I hate it some days and
I'm a first-language English user/speaker -- but putting notification
information in arbitrary scripts (even if encoded in UTF-8) without, e.g., full
language information, is just going to lead to more problems. For better or
worse, substantially everyone using email today is used to notifications and
reply messages in ASCII and based on English.
Instead, please encourage development and use of the SMTPUTF8 machinery rather
than putting pieces of what it enables and supports in small bits. The WG that
developed the specs thinks that all of the issues covered (at least about as
well as they can be). If that is not correct, we are all better off if the
problems are identified as early as possible. If it is, let's not get
distracted by patches that will constitute one more than that needs to be
worked around later.
Given that exim has an even partial experimental implementation for SMTPUTF8
(aka "EAI"), I strongly encourage those who want this particular feature to
compile it in and test it in your environment. If problems or missing bits are
found, let's get that information into the system early on.
Just my opinion, of course, but I've spent (with others) a lot of time trying
to understand the issues here and they are significantly more complex than the
bug/ feature request seems to indicate.
--
You are receiving this mail because:
You are on the CC list for the bug.
