Is 8bit Content-Transfer-Encoding Considered RFC 5322 Compliant?

Question

What I\'m trying to ascertain is whether or not emails containing 8-bit characters (in the range %x80-%xFF) - which could appear in messages or sections with a Content-Transfer-Encoding header of 8bit or binary - can ever be considered RFC 5322-compliant.

\n

I am looking for something like an industry consensus on this question, if anyone is aware of such a thing; the relevant spec documents appear to be somewhat contradictory.

\n

Google\'s new email sending guidelines state that messages must be compliant with RFC 5322, as do Yahoo\'s, so compliance is an issue to be treated seriously here.

\n

Exhibit 1:

\n

RFC 5322 states:

\n

\n

Note: This document specifies that messages are made up of characters in the US-ASCII range of 1 through 127. There are other documents, specifically the MIME document series ([RFC2045], [RFC2046], [RFC2047], [RFC2049], [RFC4288], [RFC4289]), that extend this specification to allow for values outside of that range. Discussion of those mechanisms is not within the scope of this specification.

\n

\n

I feel that leaves the matter of whether the MIME series documents describe compliant extensions to RFC 5322, or non-compliant extensions / elaborations, exactly as ambiguous as it was before the above paragraph was written. In other words, per RFC 2045, an email containing 8-bit characters may be considered a valid email, but is it a valid RFC 5322 email?

\n

Exhibit 2:

\n

The ABNF for overall message syntax in RFC 5322 reads:

\n

message         =   (fields / obs-fields)\n                       [CRLF body]\n\nbody            =   (*(*998text CRLF) *998text) / obs-body\n\ntext            =   %d1-9 /            ; Characters excluding CR\n                   %d11 /             ;  and LF\n                   %d12 /\n                   %d14-127\n

\n

This would appear to conclusively forbid the use of characters outside the 7-bit range anywhere in the message body. If I was writing a draconian parser based solely on ABNF given in RFC 5322, octets above %d127 would fail validation.

\n

Exhibit 3:

\n

Conversely, RFC 2045, which was written 12 years earlier and to which RFC 5322 makes explicit reference, provides for two values of Content-Transfer-Encoding that allow 8-bit characters in message bodies.

\n

Exhibit 4:

\n

In a test message, Google chose to encode a message body containing all ASCII characters plus \'\xc3\xb6\' using a Content-Transfer-Encoding of quoted-printable, despite the fact that the message could have been sent with 8bit as simple UTF-8.

\n

Exhibit 5:

\n

Word on th\'Internet is that use of 8bit could sometimes break DKIM validation prior to widespread adoption of the 8BITMIME SMTP extension, as a forwarding server would be forced to transcode the message body upon negotiating with a receiving MTA which did not support 8-bit characters at the protocol level. As Google & Yahoo\'s current mail initiative is largely centred around trust and authentication, they may see even a tiny risk of such problems as unacceptable.

\n

Exhibit 6:

\n

RFC 6376 (DKIM) also states that messages should be converted to 7-bit form before signing with DKIM anyway, to avoid these kinds of errors.

\n

Summary:

\n

The question has two related forms, both centred on the meaning of compliance to RFC 5322:

\n

\n

1. Will Google and Yahoo begin rejecting valid RFC 2045 email using Content-Transfer-Encoding of 8bit, on the grounds that it is not valid RFC 5322 email?

   \n
\n

2. 严格的 RFC 5322 解析器（验证器）是否应该拒绝主体包含 8 位字符的消息，即使它们使用Content-Transfer-Encoding: 8bit？

   \n
\n

\n