在Outlook中收到电子邮件时ATTnnnnn.txt附件

Question

我写了一个发送带附件的电子邮件的SMTP客户端。一切都很好，除了当我收到我的程序发送的电子邮件时，它会显示两个附件 - 实际发送的文件和一个内部有两个字符CR和LF的文件，这个文件的名称为ATT ?????。txt。

我已经完成了搜索 - 发现很多像this这样的匹配类似的问题并检查了我能做的一切。甚至更多 - 我比较了两个电子邮件 - 由我的程序发送并由Opera发送，我不能推断出差异。然而，Opera发送的内容正确解释，但我的程序发送的不是。我的程序发送的内容由一组其他邮件客户端正确解释，但不是由Outlook解释。

我已经telnet'et到SMTP服务器，将两封电子邮件检索到一个文本文件 - 一个来自我的程序，另一个来自Opera，并将它们并排比较。我没有看到任何可能影响电子邮件客户端解释的差异。

这是一个示例消息（地址替换，文件内容裁剪，空行与实际消息中显示的完全相同，行数不超过80个字符）：

To: user1@host.com, user2@host.com
Subject: subject
Content-Type: multipart/mixed; boundary="------------boundary"
MIME-Version: 1.0

--------------boundary
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

here goes the Base64 encoded text part - it may be localized, so 
it's better to UTF8 it and do Base64

--------------boundary
Content-Disposition: attachment; filename="file.jpg"
Content-Type: application/octet-stream; name="file.jpg"
Content-Transfer-Encoding: base64

here goes the Base64 encoded file data

--------------boundary

我尝试在最后一个边界之后使用换行符 - 尝试过没有，一，二，三，但这并没有改善这种情况。

是否有一些奇怪的限制，邮件客户端必须遵循这些限制才能生成由Outlook正确解释的邮件？

Answer 1

必须通过附加两个破折号来指示MIME部分的最后一个边界：

MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="------------boundary"

--------------boundary
...

--------------boundary
...

--------------boundary--

更多阅读：RFC1341 / 7.2 The Multipart Content-Type