Author: Felipe Gasper Date: To: exim-users Subject: Re: [exim] charset of "fail" messages
On 27 Nov 2015 2:24 PM, John C Klensin wrote: >
>
> --On Friday, November 27, 2015 7:10 PM +0000 Viktor Dukhovni
> <exim-users@???> wrote:
>
>>> I'm not sure I completely understand what is happening here,
>>> but, if the text you cite is part of a non-delivery
>>> notification, a body part would have to have content-type
>>> message/global-* to contain non-ASCII (specifically UTF-8;
>>> there are deliberately no other options) information. And
>>> one is not supposed to produce those notifications unless
>>> SMTPUTF8 is in use. See RFC 6533 for more information.
>>
>> The message/global MIME type is only needed for encapsulating
>> messages with non-ASCII headers. MIME body parts with UTF-8
>> content have been around long before EAI.
>
> Of course they have. Non-ASCII content/ body parts were a
> primary criterion for what became MIME, even before the
> multimedia requirements started being considered.
>
>> I receive such messages from my father (in Russian) quite
>> regularly:
>> ...
>> His email address is ASCII, and the subject is RFC 2047
>> encoded, so EAI is entirely out of scope.
>
> Again, as intended, even though some of the stronger advocates
> of EAI hope that it will gradually eliminate the need for RFC
> 2047 encoded-words.
>
> But, as I understood the question, it had to do with delivery
> failure messages (NDNs), possibly even ones that were intended
> to be machine-processed. And that is where SMTPUTF8 and
> extended notification formats come in.
>
> It appears to me that you, Jason, and I are understanding the
> issue and question differently. If Felipe still thinks there is
> a problem, some clarification from him might help.
>
Yes, NDNs, of the variety that Exim sends in response to “fail text
"..."” filters, are what my inquiry concerns.
I believe my inquiry has been answered satisfactorily: in order to have
NDNs in, e.g., Russian I need either to turn on SMTPUTF8 or transcode
the multi-byte characters down to some US-ASCII representation … the
latter of which would really be more accommodating the issue rather than
addressing it.
