--On Monday, November 30, 2015 16:47 -0600 Felipe Gasper
<felipe@???> wrote:
>> What do people particularly want worked on in the remaining
>> time? Favourite bugs?
>
> Not a bug per se, but IMO something of an "eyesore":
>
> https://bugs.exim.org/show_bug.cgi?id=1737
Felipe,
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 your
recipient-users and all of their sender-correspondents 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
you, as a mail system operator, 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,
I strongly encourage you to compile it in and test it in your
environment. If you find problems or missing bits, 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 seem to
indicate.
best,
john
