问题标签 [rfc5322]

电子邮件的 Message ID 标头有多独特？如果我将电子邮件发送给两个人，那么两个人的消息 ID 是否相同？或者他们会有所不同？

（这是假设没有人在做任何有趣的事情。我知道对于垃圾邮件，所有规则都消失了......）

我正在尝试从电子邮件中检索日期。一开始很简单：

我收到：

但我需要一个不错的日期时间对象，所以我使用：

这引起了ValueError, since %Z isn't format for +0100. 但是我在文档中找不到正确的时区格式，只有这个%Z用于时区。有人可以帮我吗？

RFC 5322 的第 3.6.2 节将回复标头定义为：

其中地址列表在第 3.4 节中定义。在展开 ABNF 语法时，我发现地址列表只能包含phrase ":" ";"（短语在第 3.2.5 节中定义）。因此，归结为您能够添加一个不包含任何实际电子邮件地址的回复标题。

RFC 规定：

当“Reply-To：”字段出现时，它指示消息作者建议将回复发送到的地址。

即使只是一个建议，我可以建议某人回复我命名但未指定的地址，这似乎很奇怪。

我在这里错过了什么吗？我应该如何解释这样的结构？

电子邮件标头是否区分大小写？

例如，Content-Type不同于Content-type?

根据RFC 5322，我看不到任何关于区分大小写的内容。但是，我发现使用 PEAR Mail_mime 模块创建 MIME 消息时出现问题，并且一切都表明我们的 SMTP 服务器使用Content-typeandMIME-version而不是Content-Typeand MIME-Version。我尝试使用另一个 SMTP 服务器（如 GMail），但不幸的是，我们的网络服务器防火墙非常严密。

我想Message-ID使用 ActionMailer 更改从 Ruby on Rails v3 应用程序发送的电子邮件的标题部分中的标题。

我在本地主机上使用 Sendmail 进行邮件传递。

我应该在 Sendmail 或 ActionMailer 中配置它吗？

我在哪里配置它（如果是 ActionMailer）：文件config/夹中的文件或 app/mailers/ 文件夹中的文件？

PHP 手册 (http://php.net/manual/en/function.mail.php) 说：

每行应该用 LF (\n) 分隔。行不应超过 70 个字符。

但实际的 RFC 5322 给出了完全不同的信息：

2.3. 正文 消息的正文只是几行 US-ASCII 字符。主体上仅有的两个限制如下：
o CR 和 LF 必须仅作为 CRLF 一起出现；它们不得独立出现在体内。o 正文中的字符行必须限制为 998 个字符，并且应该限制为 78 个字符，不包括 CRLF。

所以 - RFC 说只应该使用 \r\n 。我不明白 - php mail() 如何在后台工作？

我这可能是一个奇怪的问题，但我想我会继续问。比如说，我通过一个特殊的客户端使用IMAP SMTP发送一封电子邮件。此客户端在发送电子邮件之前向电子邮件添加了一些自定义标头。收件人收到这封电子邮件并直接回复我（可能还有 CC 的几个人）。

我的问题是：鉴于上述示例，这些 X-headers 是否会在线程中的所有新消息中持续存在？

我能想到的一件事是客户会知道它发送的原始电子邮件。对此电子邮件的所有后续响应都将具有一个“Reply-To”标头，其值等于上一封电子邮件的“Message-Id”。我不明白为什么在我得到客户端发送的原始消息之前我无法爬取这些回复线程，从而派生出原始的自定义标头。

也许我在想这个。有什么建议么？:)

我在 mime 解析库中遇到了一个错误，它在包含超过一定长度的外来字符的主题行上爆炸。事实证明，它会将主题转换为 Quoted-Printable MIME“ Encoded-Word ”，然后尝试将整个内容自动换行为 78 个字符。因为 MIME-Word 编码没有空格（它们被下划线替换）它无法换行。

被换行的示例行：

我想我可能会为库提供一个补丁以正确换行，但我找不到关于如何将 MIME-Word 分解为自动换行算法的一部分的参考资料。

RFC 5322说要在空格处进行自动换行，但没有提供任何关于如果没有超过目标宽度的空格的字符串该怎么做的指导。

有人知道在这里采取的正确行动吗？

我经常看到自动电子邮件后缀有这样的消息

亚马逊：

*请注意：这封电子邮件是从一个不能接受来电的地址发出的。如果您需要再次就同一问题与我们联系，请使用上面的链接。

推特：

请不要回复这个信息; 它是从一个不受监控的电子邮件地址发送的。此消息是与您使用 Twitter 相关的服务电子邮件。

谷歌结帐：

需要帮忙？访问 Google Checkout 帮助中心。请不要回复这个信息。

在此警告的正下方，Gmail 向我显示了一个回复输入字段。在我看来，应该有某种标题可以附加到这样的自动电子邮件中，告诉收件人的电子邮件客户端不允许回复。

有这样的标题吗？如果没有，控制电子邮件格式的小组是否曾讨论过它？

RFC 5321、5322和6531具有用于验证电子邮件地址的复杂规则。他们：

• 允许在电子邮件地址中创建评论
• 为符号提供复杂的限制规则："() ,:;<>@[\]
• 将postmasterlocalpart 视为不区分大小写，但将所有其他视为区分大小写
• 允许电子邮件地址组

由于这些复杂的规则，仅使用正则表达式无法执行根据 RFC 测试给定字符串是否是语法上有效的电子邮件地址。

显然，其中许多规则不受主要电子邮件提供商的支持。

从历史上看，为电子邮件地址创建如此复杂的规则的动机是什么？关于电子邮件起源的Wikipedia 文章似乎暗示 1980 年代初期的现代标准旨在涵盖所有具有特定标准和语法的遗留电子邮件系统。

然而，标准的实施者、电子邮件提供商和电子邮件最终用户都对一个工作系统有既得利益，当规则不是太神秘时更容易实现，并且可以很容易地投入到通过有限数量测试的软件中，那么为什么我们今天有一个如此复杂的标准，却没有人充分使用它？

从历史上看，XML 在很大程度上已被 JSON 取代，JSON 的成功部分归功于其语法的简单性。