我写了一个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正确解释的邮件?
必须通过附加两个破折号来指示MIME部分的最后一个边界:
MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------boundary" --------------boundary ... --------------boundary ... --------------boundary--
更多内容:RFC1341/7.2多部分内容类型