--On Monday, November 30, 2015 16:47 -0600 Felipe Gasper <[email protected]> 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 -- ## List details at https://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
