--On Friday, November 27, 2015 7:10 PM +0000 Viktor Dukhovni
<[email protected]> 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.
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/
