【发布时间】：2020-04-27 03:40:05
【问题描述】：
我目前正在开发一个 gmail 插件。该插件会向特定收件人发送一封电子邮件，并附上 eml 文件。不幸的是，收件人无法打开我通过 GMAIL API 发送的电子邮件所附的 eml 文件。如果他们单击附加的 eml 文件，他们将收到消息“加载附加消息时发生错误”。
我在分析单击电子邮件上的“显示原始”时看到的数据时，发现了两个可能与此问题有关的问题。一个是我通过 GMAIL API 发送的所有电子邮件都有“从 xxxxxxxxxxx 接收，gmailapi.google.com 命名为未知，带有 HTTPREST”标题。并且电子邮件内容中缺少整个 base64 编码的 eml 文件。请看下图：
这与Emails sent via GMAIL API are flagged as Phishy 有关吗？还是我错过了或做错了什么？如果我将“附件类型”设置为“文本/纯文本”，那么当我“显示原始”电子邮件时，base64 编码的 eml 文件数据就会存在并且可以查看。提前谢谢大家。
【问题讨论】：
-
对于使用 Gmail API 发送的邮件，不要担心“使用 HTTPREST 从 gmailapi.google.com 名称未知的 xxxxxxxxxxx 接收”，这不会影响邮件的可读性。至于你的编码：你的文件是base64编码还是base64ur编码？
-
谢谢@ziganotschka 它只是base64Encoded。我需要使用 base64URLEncoded() 吗？谢谢。
-
是的，需要base64URLEncoded，看这里：developers.google.com/gmail/api/v1/reference/users/messages/…
-
我也会试试的。但是，如果我将 eml-attachment 内容类型设置为“text/plain”而不是“message/rfc822”，为什么它可以正常工作？而且，如果我下载使用 content-type="message/rfc822" 发送的 eml 附件，下载的 eml 文件可以在 Outlook 中完美查看。另一个令人困惑的情况是当我“显示原始”时缺少 eml 文件内容。但是，如果我将附件内容类型设置为“文本/纯文本”，我可以在“显示原始”时看到整个数据。如果这是一个简单的编码案例，下载 eml 文件不会太有效吧？还是我弄错了？谢谢。
-
我不熟悉 eml 文件，但 Gmail 需要 RFC 2822 格式。请注意 RFC 2822 取代了 RFC 822（或者换句话说：RFC 822 已过时）。 tools.ietf.org/html/rfc2822
标签： gmail gmail-api gmail-addons