来自邮件客户端的电子邮件格式答案

【问题标题】：Email formatting from mail clients来自邮件客户端的电子邮件格式
【发布时间】：2013-11-30 23:37:18
【问题描述】：

我一直在对标准化电子邮件格式进行一些研究/测试。最终，我希望为应用程序开发电子邮件解析器。我注意到电子邮件格式存在一些差异，主要存在于电子邮件客户端（gmail、mac mail 等）和电子邮件营销服务（Constant Contact、Mail Chimp 等）之间。

我对格式 (RFC2822) 的理解是 \n\n 将标题与正文分开。这些似乎与从电子邮件营销服务收到的电子邮件一致。然而，电子邮件客户端似乎有一组额外的邮件标题或说明。请参阅下面的电子邮件字符串示例。请注意，我通过电子邮件管道提取了这些字符串。另请注意，这些只是标题/正文拆分的 sn-ps。

电子邮件营销服务：

Content-Type: text/html;
    charset="utf-8"
Content-Transfer-Encoding: 8bit

 
<html>
<head>
    <title>Welcome to Banana Republic. Enjoy 25% off!   </title>
<STYLE type="text/css">
.ReadMsgBody
{ width: 100%;}
.ExternalClass
{width: 100%;}

在这里，您将看到将标题与正文分开的换行符。根据格式，一切都很好。现在看看电子邮件客户端。

电子邮件客户端：

Mime-Version: 1.0 (Mac OS X Mail 7.0 (1816))
X-Mailer: Apple Mail (2.1816)


--Apple-Mail=_28DD752B-7960-488D-994F-DA9408FCA880
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
    charset=windows-1252

Testing Mac Mail. This is the body.

您会看到，在这种情况下，有一组额外的“标题”似乎是关于在这种情况下 Mac Mail 如何格式化电子邮件的说明。

我想我的问题是，这是一种有效的格式吗？有什么规范吗？是否有任何众所周知/记录在案的方法来检查和解析这种类型的格式而不知道正在接收哪种类型的格式？

【问题讨论】：

您需要查看多个其他 RFC，例如 RFC2045-2047（MIME 编码）以及它们如何描述多部分消息。我假设您的第二个片段不包括 Content-Type: multipart/mixed; boundary=Apple-Mail=_28DD752B-7960-48 8D-994F-DA9408FCA880 我希望将其视为其中的一部分（您可以有多个子部分，每个子部分都符合 RFC2822 规则）。正确和完整的电子邮件解析是困难的。允许的东西遍布各处。
注意这个链接，它引用了许多与电子邮件相关的 RFC：lsoft.com/manuals/Maestro/2.1/Users/WebHelp/…
@Joe - Content-Type: multipart/alternative 实际上。不确定这是否会有所不同，但我正在查看您提供的 RFC 参考资料，看看是否可以了解更多信息。
作为几个强大的电子邮件解析器（GMime、MimeKit、Camel 等）的作者 - 请不要实现自己的解析器/生成器，除非您致力于正确实现所有内容而不是另一个- 快速而肮脏的解析器，最终只会使人们编写真正的解析器的工作变得更加困难，因为很多人编写的解析器/生成器都弄错了。

标签： email format standards rfc2822

【解决方案1】：

[cmets中的扩展点]

这是一种有效的格式吗？

是的。比严格的 7 位 ASCII 文本更复杂的邮件消息的整体框架称为 MIME。它在您的第一个示例中包含“Content-Type”标头的规范，通知客户端整个消息是 HTML 而不是纯文本。如今，许多（可能是大多数）消息在最外层属于“multipart/alternative”类型，封装了消息体的 2 个（或更多！）版本，通常是 text/plain 表示和 text/html 版本，它本身就是通常在包含嵌入图像的多部分/混合容器中。

有什么规范吗？

是的。 MIME 的基础知识在 RFC 的 2045-2049 中进行了描述，并且在许多后来的 RFC 和类型注册文档中描述了许多扩展和更正。 MIME 还提供了 HTTP 文档规范的核心组件，因此许多扩展几乎与电子邮件无关。

是否有任何众所周知/记录在案的方法来检查和解析这个不知道接收的是哪种格式的格式？

是的。虽然几乎所有现代电子邮件都是 MIME 格式，但正式地您可以通过查找“MIME-Version”标头来检测它。有关详细信息，请参阅 RFC2045。请注意，您的第一个示例没有显示该标题，但它必须存在于完整的原始文件中，否则您显示的标题将毫无意义。

这说明了为什么您可能应该重新考虑编写自己的邮件解析器的想法。您所看到的两种格式实际上并不是这样，它们只是 MIME 格式框架的不同应用。 MIME 比 RFC2822 早得多（顺便说一下，RFC5322 本身已经过时）并且有许多成熟和强大的解析器可用。编写一个适用于大多数邮件的 MIME 解析器很容易，编写一个适用于几乎所有有效邮件的 MIME 解析器有点困难，而编写一个能够安全处理现实世界的邮件的程序是一个挑战t 完全正确，并且在某些情况下旨在以恶意方式破坏幼稚的解析器。利用在您之前数十年的编码人员被撕毁的头发：使用现有的解析器。

【讨论】：