On Fri, Nov 27, 2015 at 01:23:03PM -0500, John C Klensin wrote:
> > The argument to "fail text" is put into the message body,
> > not the headers … ?
>
> 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.
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Mostly ASCII body with occasional UTF-8
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: base64
Substantially non-ASCII body
I receive such messages from my father (in Russian) quite regularly:
Content-Type: multipart/alternative; boundary="Apple-Mail=_5623C0E6-30AD-4544-BBBD-2C63E30024BB"
Date: Tue, 24 Nov 2015 22:10:19 +1100
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
X-Mailer: Apple Mail (2.2104)
--Apple-Mail=_5623C0E6-30AD-4544-BBBD-2C63E30024BB
Content-Transfer-Encoding: base64
Content-Type: text/plain;
charset=utf-8
<base64 encoded Russian text>
--Apple-Mail=_5623C0E6-30AD-4544-BBBD-2C63E30024BB
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
charset=utf-8
<base64 encoded Russian text in HTML format>
--Apple-Mail=_5623C0E6-30AD-4544-BBBD-2C63E30024BB--
His email address is ASCII, and the subject is RFC 2047 encoded,
so EAI is entirely out of scope.
--
Viktor.
