我想要确定的是，包含 8 位字符（在范围内%x80-%xFF）的电子邮件（可能出现在带有Content-Transfer-Encoding或标题的消息或部分中8bit）binary是否可以被视为符合 RFC 5322 标准。
如果有人知道这样的事情，我正在寻找关于这个问题的类似行业共识；相关的规范文件似乎有些矛盾。
谷歌的新电子邮件发送指南声明消息必须符合 RFC 5322，雅虎，因此合规性是一个需要认真对待的问题。
图表 1：
RFC 5322状态：
注意：本文档规定，消息由 US-ASCII 范围（1 到 127）内的字符组成。还有其他文档，特别是 MIME 文档系列（[RFC2045]、[RFC2046]、[RFC2047]、[RFC2049]、[RFC4288]、[RFC4289]），扩展了本规范以允许超出该范围的值。这些机制的讨论不在本规范的范围内。
我觉得剩下的问题是 MIME 系列文档是否描述了合规RFC 5322 的扩展，或不合规扩展/阐述，与上面这段话写出来之前一样含糊不清。换句话说，每RFC 2045，包含 8 位字符的电子邮件可能被视为有效的电子邮件，但它是有效的 RFC 5322 电子邮件吗？
图表 2：
ABNF 适用于总体消息语法在 RFC 5322 中写道：
message = (fields / obs-fields)
[CRLF body]
body = (*(*998text CRLF) *998text) / obs-body
text = %d1-9 / ; Characters excluding CR
%d11 / ; and LF
%d12 /
%d14-127
这似乎决定性地禁止在邮件正文的任何地方使用 7 位范围之外的字符。如果我编写一个仅基于 RFC 5322 中给出的 ABNF 的严格解析器，则上面的八位字节%d127将无法通过验证。
图表 3：
相反，RFC 2045 是在 12 年前编写的，RFC 5322 明确引用了它，提供两个值Content-Transfer-Encoding允许在消息正文中使用 8 位字符。
图表 4：
Content-Transfer-Encoding在一条测试消息中，Google 选择使用of对包含所有 ASCII 字符加“ö”的消息正文进行编码quoted-printable，尽管该消息可以使用8bit简单的 UTF-8 发送。
图表 5：
互联网上的话语在广泛采用 8BITMIME SMTP 扩展之前，使用8bit有时会破坏 DKIM 验证，因为转发服务器在与不支持协议级别 8 位字符的接收 MTA 协商时将被迫对邮件正文进行转码。由于 Google 和 Yahoo 当前的邮件计划主要以信任和身份验证为中心，因此他们可能会认为即使是微小的此类问题风险也是不可接受的。
图表 6：
RFC 6376 (DKIM) 也状态无论如何，在使用 DKIM 签名之前应该将消息转换为 7 位形式，以避免此类错误。
概括：
该问题有两种相关形式，均围绕遵守 RFC 5322 的含义：
Google 和 Yahoo 是否会开始拒绝使用有效的 RFC 2045 电子邮件
Content-Transfer-Encoding，8bit理由是不是有效的 RFC 5322 电子邮件？严格的 RFC 5322 解析器（验证器）是否应该拒绝正文包含 8 位字符的消息，即使它们使用
Content-Transfer-Encoding: 8bit？