我已经编写了一个发送带有附件的电子邮件的 SMTP 客户端。一切都很好，除了当 Outlook 收到我的程序发送的电子邮件时，它会显示两个附件 - 实际发送的文件和一个包含两个字符 CR 和 LF 的文件，该文件的名称为 ATT?????.txt。
我已经完成了搜索 - 找到了很多匹配项，例如 this对于类似的问题，并检查了我能做的一切。甚至更多 - 我比较了两封电子邮件 - 由我的程序发送和由 Opera 发送，我无法推断出差异。但是 Opera 发送的内容被正确解释，但我的程序发送的内容却没有。我的程序发送的内容由一组其他邮件客户端正确解释，但不是由 Outlook 解释的。
我已经 telnet'et 到 SMTP 服务器，将两封电子邮件检索到一个文本文件中 - 一个来自我的程序，另一个来自 Opera，并将它们并排比较。我没有看到任何可能影响电子邮件客户端解释的差异。
这是一个示例消息(地址被替换，文件内容被裁剪，空白行与实际消息中的显示完全相同，行数不超过 80 个字符):
至:user1@host.com，user2@host.com
主题:主题
内容类型:多部分/混合；边界="------------边界"
MIME 版本:1.0
- - - - - - - 边界
内容类型:文本/纯文本；字符集=“utf-8”
内容传输编码:base64
这里是 Base64 编码的文本部分 - 它可能是本地化的，所以
最好是UTF8它并做Base64
- - - - - - - 边界
Content-Disposition:附件；文件名=“文件.jpg”
内容类型:应用程序/八位字节流；名称=“文件.jpg”
内容传输编码:base64
这里是 Base64 编码的文件数据
- - - - - - - 边界
我尝试在最后一个边界之后使用换行符 - 尝试了无、一、二、三，但这并没有改善情况。
是否有一些奇怪的限制邮件客户端必须遵循以生成由 Outlook 正确解释的邮件？
最佳答案
MIME 部分的最后一个边界必须通过附加两个破折号来表示:
MIME 版本:1.0
内容类型:多部分/混合；边界="------------边界"
- - - - - - - 边界
...
- - - - - - - 边界
...
- - - - - - - 边界 -
更多阅读在这里:RFC1341 / 7.2 The Multipart Content-Type
关于email - 在 Outlook 中收到电子邮件时的 ATTnnnnn.txt 附件，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/690430/