问题标签 [rfc2822]

我正在开发一个 RFC 2822 地址解析器（不是验证器），并且想知道是否有人知道一个很好的测试用例列表来练习可能出现的极端案例？地址格式的规范非常复杂，我不相信我完全理解它以确保识别所有可能出现的奇怪情况。

为了清楚起见，我说的是地址，因为它们可能出现在标题行中，所以像奇怪地方的注释之类的东西是我正在考虑的问题。

我正在使用考虑到 RFC 2821 的 java 进行电子邮件验证。我使用以下代码来验证我的所有电子邮件地址：

Java api 表示其符合 RFC-822。RFC 2821 和 822 之间有很大区别吗？

在以下情况下，上述 api 也无法验证电子邮件：

1. var@yahoo- 验证返回真，但它是无效的电子邮件
2. var(comment)@yahoo.com- 验证返回 false，但它是有效的电子邮件

你能告诉我任何解决这个问题的方法来完成它。

我一直在测试 BigCommerce API 调用，

首先我尝试了orders.json 调用，我确实得到了正确的答复。

但是当我添加日期范围参数即 min_date_created 和 max_date_created 时，它给了我错误。

我正在使用 PHP cURL 对其进行测试，以下是 URL：

以下是我得到的错误：

谁能告诉我哪里出错了？

谢谢，

我有一封带有如下标题的原始电子邮件：

我不知道如何解释前两行，最初阅读RFC2822让我毫无头绪。它们看起来不像普通的标头，并且设法使 Python 2.7 电子邮件解析器感到困惑（如果我删除>了第二行开头的符号就可以了）。我在 Apple 邮件的缓存中有相同的电子邮件正文，看起来很好，所以输入显然是正确的。

1. 什么是标题格式？( From <email> <date>\r\n)
2. 为什么第二个以>（更大的符号）为前缀？

许多人不知道，电子邮件地址需要一个库来解析。简单的正则表达式，如@(.*)，是不够的。电子邮件地址甚至可以包含评论，其中可以包含诸如@破坏简单正则表达式之类的字符。

有一个解析 RFC 2822 地址的Node.js 库：

这几乎是 perl 模块的直接端口Mail::Address。

这是我希望在 Java 的InternetAddress类中存在的东西，但它不会比完整地址进一步分解，它可以包括例如user@gmail.com. 但是我正在尝试提取该gmail.com部分，它不包括要执行的方法。

我很惊讶我找不到解决这个问题的通用库，但想必很多人都有这个问题。如何使用图书馆或不使用图书馆来解决这个问题？

我目前正在研究在 C# 中序列化 MailMessage 对象，虽然网络上有几个示例的变体，但它们序列化为二进制，这与 IMO 的要点无关。

我的方法是我想将 MailMessage 序列化为 RFC2822 eml 字符串，下面的代码就是我想出的。

这很讨厌，但它确实有效。不过，理想情况下，我会创建一个新的 SMTPClient 并添加一个 Serialize 函数，该函数会自动返回 rfc822 字符串，而不会影响文件系统。

由于我似乎无法使用 Visual Studio 追踪到 SMTPClient.Send 函数，因此这种“理想”的做事方式有点棘手。

我已经通过对 Peter Huber 的 POP3MimeClient 和 POP3MailClient 类添加一些小的更改来整理 RFC 消息的反序列化，以便我可以将 HDD 上的文件或字符串反序列化回 MailMessage。

困扰我的是，我真的应该能够使用流序列化 MailMessaage 并将流写入我选择的字符串或文件，而不是像上面的代码那样四处走动以创建基于 GUID 的文件夹并将文件的内容读回字符串...

任何关于我如何使它更优雅的指针都将不胜感激。

谢谢。

我想为使用Python 的内置库创建的消息添加一个唯一的符合RFC2822的标头。我该怎么做呢？图书馆本身有办法吗？Message-IDemail

在 RFC 822 中，要求目标地址出现在标题中，第 C.3.4 节。读取“一条消息必须包含至少一个目标地址字段。'To' 和 'CC' 必须包含至少一个地址。” 在 RFC 2822 和 5322 中，第 3.6 节。在两者中，他们都写道：“唯一需要的标题字段是发起日期字段和发起人地址字段。”

我对这种变化背后的原因很感兴趣。我知道 IETF 有邮件列表档案和会议纪要，但是如果邮件列表中记录了这些，我很难在档案中找到它。

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

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

电子邮件营销服务：

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

电子邮件客户端：

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

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