https://bugs.exim.org/show_bug.cgi?id=1737
John Klensin <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #1 from John Klensin <[email protected]> --- 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. -- ## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
