问题标签 [rfc5322]

我试图理解rfc5322 Line Length Limits 。行限制是 78 个字符还是 998 个字符？一个用于正文，另一个用于标题？我找不到任何东西来说明这一点。

Each line of characters MUST be no more than 998 characters, and SHOULD be no more than 78 characters, excluding the CRLF.

根据rfc5322，您需要在 78 个字符后换行（添加 CRLF）。

我的问题是如何解码文本/正文（删除 CRLF）？我如何知道编码器添加了哪个 CRLF，哪个是原始正文内容的一部分？我已经检查了一些实现，但它们中的大多数似乎并不在意编码规则是强制执行的。

我一直在阅读 RFC、摘要、维基百科等。我对本地部分与标签感到非常困惑。在我看来，本地部分在@之前。这看起来很简单。标签是由点分隔的域的任何部分。但在我看来，有些地方也将本地部分称为标签。在允许使用连字符的情况下，这非常令人困惑。那么具体什么是标签呢？

有了这个，其中哪些是有效的电子邮件地址（如果有的话）？

我的理解是标签既不能以连字符结尾也不能以连字符开头，并且不能包含两个连续的连字符。我错过了什么吗？

加分 - 本地部分允许使用许多特殊字符，但我看到的一些消息来源说本地部分必须以字母数字字符结尾，但我实际上并没有在任何标准中看到这一点。我错过了它还是可以以允许的字符之一结尾？

我正在尝试解析 RFC5322 电子邮件地址。我的解析器的工作原理是在结果中，其中一个是正确的。但是，我该如何选择“正确”的结果呢？

给定字符串Foo Bar <foo@bar.com>，我的解析器应该产生一个Address (Just "Foo Bar") "foo@bar.com".

或者，给定字符串foo@bar.com，我的解析器应该产生Address Nothing "foo@bar.com".

包含名称的值是首选。

我的解析器如下所示：

当我使用 运行解析器时readP_to_S rfc5322 "Foo Bar <foo@bar.com>"，它会产生以下结果：

在这种情况下，我真正想要的结果出现在列表的倒数第三位。我如何表达这种偏好？

根据RFC5322和以下验证电子邮件 ID

https://en.wikipedia.org/wiki/Email_address

下面是使用 java 和正则表达式来验证电子邮件 ID 的示例代码。

实际输出：

预期输出：

如何更改我的正则表达式，使其使以下电子邮件 ID 模式无效。

以下是正则表达式的标准：

局部

电子邮件地址的本地部分可以使用以下任何 ASCII 字符：

1. 大写和小写拉丁字母A to Z和a to z；
2. 数字0 to 9;
3. 特殊字符 !#$%&'*+-/=?^_`{|}~
4. dot .，前提是它不是第一个或最后一个字符，除非被引用，并且它不连续出现，除非被引用（例如John..Doe@example.com，不允许但 "John..Doe"@example.com允许）；
5. space和"(),:;<>@[\]字符是有限制的（它们只允许在带引号的字符串中，如下文所述，此外，反斜杠或双引号必须以反斜杠开头）；允许在本地部分的任一端带括号的注释；例如 john.smith(comment)@example.com和 (comment)john.smith@example.com都等价于 john.smith@example.com。

领域

1. 大写和小写拉丁字母A to Z和a to z；
2. 数字0 to 9，前提是顶级域名不是全数字的；
3. hyphen -，前提是它不是第一个或最后一个字符。域和本地部分都允许评论；例如john.smith@(comment)example.com和 john.smith@example.com(comment)等价于 john.smith@example.com。

我最近遇到了一个我想用 Python 电子邮件模块解析的 EML 文件。在from标题中，有以下文字：

所以名称被编码为两部分。当我连接代码并将其手动解码为十六进制时，我得到以下结果，这是正确的 UTF-8 字符串：

但是，当我调用 Python 电子邮件 Parserparse时，最后 3 个字节未正确解码。相反，当我读取 的值时message['from']，有代理项：

因此，例如，当我想要打印字符串时，它会以

当我将From标头中的 2 个编码部分合二为一时，如下所示：

该字符串由库正确解码，可以很好地打印。

这是 Python 电子邮件模块中的错误吗？EML标准是否允许双重编码值？

这是一个示例 EML 文件 + Python 代码，用于重现错误解码（这实际上不会触发异常，稍后会发生这种情况，即 SQLAlchemy 无法将字符串编码回 UTF-8）

EML：

Python代码：

结果：

彭以国/第二事业部项目部/第二事业部 ��

我正在使用 smtplib 创建一个 MIMEMultipart 电子邮件，结果是一个如下所示的标题。

这是一个有效的电子邮件标题吗？除了一个人在显示电子邮件正文之前遇到他们的电子邮件被切断之外，没有遇到任何投诉。他们声称这是因为 Content-Type 出现在错误的位置。

这就是消息的创建方式

我从评价最高的 Stackoverflow 答案中获取了这个正则表达式，以使邮件符合 RFC 5322，并且它似乎工作正常。

我还想否定+在字符串的任何部分的出现。我应该在哪里进行更改

一家电子邮件提供商拒绝了一封包含特殊字符（例如变音符号）的电子邮件。他们说它们符合 RFC-5321 和 RFC-5322。现在我浏览了这些标准，但是它们不支持国际电子邮件（因此没有变音符号）。仅支持 ASCII-127。现在有一个名为 RFC-6532 的扩展，用于标准化国际电子邮件。我们的电子邮件采用 UTF-8（可引用打印）编码并发送如下：

"=?UTF-8?Q?B=C3=B6rge_M=C3=B6ller?="<boerge.moeller@foo.org>

这是一个符合 RFC-6532 的地址吗？还是其他一些/较旧的 RFC（如 RFC-2054）？毕竟有这么多与邮件相关的 RFC，我可能错过了 10 或 20 个 ;-)

在解析 MBox 文件的集合时，我遇到了数量惊人的表单的 Date 标头字段：

"Date:" date-time "<" addr-spec ">"

阅读可用的 RFC，我发现没有匹配的语法。有效的形式似乎是：

"Date:" date-time [CFWS]

CFWS 表示注释和折叠空格，如 RFC5322 的第 3.3 节（日期和时间规范）中所述。

阅读正确的邮件日期标题格式，作者分析了 132k 日期标题，但上面的表格从未显示在链接的数据集中。

这是 MBox 人工制品、IMF 属性还是来自邮件代理和/或邮件中继的损坏？

Internet 消息格式自 1980 年代以来一直在发展，它有点混乱，并且已经以多种方式解释，例如 HTTP。我倾向于这是一个特定于供应商的修改，导致日期标题字段格式错误？身份证。

示例 MBox

规格

• RFC 5322
• RFC 2822
• RFC 822
• RFC 4021
• MBox 格式
• MBOXO 格式
• MBOXRD 格式
• MBOXCL 格式
• MBOXCL2 格式
• RFC 5321
• RFC 2821