我正在尝试使用 Gmail API 回复现有电子邮件：

由于我在现有邮件中没有我想回复参考的标题， 因此我使用 Message-ID 来填充我发送的内容

DB5PR03MB1206D3A24F124BDF43A5C6E683D60@DB5PR03MB1206.eurprd03.prod.outlook.com 是现有邮件的 Message-ID 标头。

我创建了以下 RFC-802：

然后我得到一个错误：

发生错误消息未发送。

我读了这篇文章，但这篇文章假定我总是有以下两个标题：

1. 参考
2. 回复至

查看date的手册页，我找不到转换为 rfc822 的标准方法（例如：来自 unix 时间戳）。我简要地看了一下规范，但我对主题的了解还不够，无法获得正确的格式。有没有一种简单的方法可以使用标准的 linux 终端工具转换为 rfc822？

一直在浏览旧帖子，但到目前为止只找到了识别发件人、收件人、主题的解决方案。我正在寻找可以分析 Internet 标头的代码，类似于https://testconnectivity.microsoft.com/MHA/Pages/mha.aspx和https://toolbox.googleapps.com/apps/messageheader等工具/。

我希望能够提取例如 From、Reply-to、submitting MX、X-originating IP、X-mailer。我应该从头开始创建解析器还是有什么可以使用的？也许是样品或您可以分享的东西？

最好的，弗雷德里克

RFC 5988的第 5 节定义了 Link 标头的语法如下：

本规范使用RFC 822中定义的增强型 Backus-Naur 形式 (BNF) 。

如果正确理解 BNF，规范不允许分号 ( ;) 和link-param. 但是，在第 5 节中出现的示例中，两个元素之间存在空格：

我还在 Github 的 API 中观察到 Link 标头中的空白，我认为这是更符合标准的 API 之一：

空格应该是允许的吗？除了这些例子之外，我找不到任何可以提供证据的东西。

我试图在 .NET 中获取 MailMessage 以返回 MIME 消息的字符串，但这在传递的类中没有提供。关于如何创建 C# 扩展方法来猴子修补类以提供功能还有另一个很好的答案。我正在尝试使用类型扩展将其移植到 F#，但我对如何提供参数感到困惑（特别是考虑到其中一个参数是 F# 关键字）。

非常感谢您解释如何通过答案正确完成此操作。

这是我到目前为止所得到的（当然，目前还不能编译）：

我正在使用 ClamAV，通过 Unix 套接字进行通信，例如https://github.com/Elycin/php-clamav/。到目前为止所有工作。

我的应用程序从文件夹中提取文件。每个文件都包含符合 RFC822 的内容（有时您会看到这些带有扩展名 .eml）。

我打算编写代码将 .eml 文件解压缩为单独的正文和多个附件。然而，快速测试表明，如果我只是将整个 .eml 文件写入clamd套接字，例如 EICAR 测试文件作为附件，则会clamd扫描并报告“受感染”文件。

我想知道这是否可以依赖，即 clamd 是否总是彻底解压并检查嵌入的 MIME 部分电子邮件附件，还是我只是在测试中“走运”？我不想相信运气。

我正在使用 python 2.7 并尝试解析作为附件转发到收件箱的电子邮件。我似乎无法解析附加邮件的标题/电子邮件。我将其视为“消息/rfc822”，但是当我尝试解析它时，它显示为空。

我通过生成器提取消息，它工作正常，如下所示：

然后将此消息推送到另一个函数中，我在其中拉附件（通过 walk()）

附件类如下：

我尝试使用 get_payload 拉取附件并使用 as_string() 传递它（如上），但无济于事。当我尝试解析电子邮件附件时，它没有得到任何数据：

我现在正在使用 Dsync，一个 ipaas。

我想从另一个来源（JIRA）发送带有 gmail 的消息。

由于 Dsync 在正文中提供自动花括号，因此我不能像下面那样遵循 rfc822 格式。

相反，Dsync 为它们提供如下花括号。

有没有办法用花括号发送 gmail 或 rfc822？或带有标题。谢谢。

谷歌文档给出了一个例子如下：

POST /upload/gmail/v1/users/userId/messages/send?uploadType=multipart HTTP/1.1 主机：www.googleapis.com 授权：承载 your_auth_token 内容类型：multipart/related；边界=foo_bar_baz 内容长度：number_of_bytes_in_entire_request_body

--foo_bar_baz 内容类型：应用程序/json；字符集=UTF-8

{“id”：字符串，“threadId”：字符串，“labelIds”：[字符串]，“snippet”：字符串，“historyId”：无符号长，“payload”：{“partId”：字符串，“mimeType”：字符串, "filename": 字符串, "headers": [ { "name": string, "value": string } ], "body": users.messages.attachments Resource, "parts": [ (MessagePart) ] }, " sizeEstimate”：整数，“原始”：字节 }

--foo_bar_baz 内容类型：message/rfc822

电子邮件消息数据 --foo_bar_baz-- 如果请求成功，服务器将返回 HTTP 200 OK 状态代码以及任何元数据：

HTTP/1.1 200 内容类型：application/json

{“id”：字符串，“threadId”：字符串，“labelIds”：[字符串]，“snippet”：字符串，“historyId”：无符号长，“payload”：{“partId”：字符串，“mimeType”：字符串, "filename": 字符串, "headers": [ { "name": string, "value": string } ], "body": users.messages.attachments Resource, "parts": [ (MessagePart) ] }, " sizeEstimate”：整数，“原始”：字节 }

有人可以通过查看上面的示例来制作示例请求正文吗？我需要发送带有附件的电子邮件。

我被 RFC 7578 和它所指的 RFC 中看似隐式允许的空格所困扰，虽然似乎在允许这样的空格时，应该明确说明。由于同样的空白故事，我也对我认为的模棱两可感到困难。

RFC 7578 at 4.2关于“Content-Disposition”，给出了这个例子：

它这样做是指 RFC 2183。这个RFC 2183 at 2给出了没有明确提及空白的 BNF 规则（WSP 和 LWS 都没有），虽然上面 RFC 7578 的示例很明显使用了空白，而规则没有提到这一点：

RFC 2183 指的是 RFC 822，现在是 RFC 2822。这个RFC 2822 在 3.2.4和3.2.5中明确提到了原子（或点原子）和引用字符串周围的 CFWS。在其他地方，它说基于此 RFC 的语法依赖于它定义的标记化。

因此，“form-data”和“name”可能是 RFC 2822 之后的原子，这可以解释为什么在示例中两者之前都可以出现空格（“;”将是一个特殊字符，因此是一个标记）。但是RFC 2822 所指的 3.1 的 RFC 2234说：

任何希望在分隔符或字符串段周围允许线性空白的语法都必须明确指定它。[…]

然后，仍然与上面的示例大致相同，如果它是由原子组成的，那么“name”“=”是模棱两可的，因为“name=”同样是一个原子，并且没有规则说明“”之间是否允许有空格名称”和“=”，这正是让我感到模棱两可的原因。

这只是一个例子，我只是觉得在这些标准的其他地方也不清楚。

是否可以将其理解为：它由原子（和带引号的字符串）组成，并且在原子（和带引号的字符串）周围允许有空格，尽管某些 RFC 没有明确说明它们中的空格或原子的任何内容规则，而他们应该？

更新

顺便说一句，这些 RFC 似乎根本不是指原子/点原子，而是指一种由除tspecials之外的任何可打印字符组成的令牌，在多个地方定义相同，一组字符看起来很像来自RFC 822，虽然不同。此令牌定义与 RFC 822/2822 中的不同。尽管引用了 RFC 822，但这些 RFC 似乎重新定义了自己的符号。空白仍然不清楚。