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

Question

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

我做的搜索-发现了很多类似的比赛本类似的问题,并检查尽我所能.甚至更多 - 我比较了两个电子邮件 - 由我的程序发送并由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多部分内容类型