在 Outlook 中收到电子邮件时的 ATTnnnnn.txt 附件 [英] ATTnnnnn.txt attachments when e-mail is received in Outlook

问题描述

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

我进行了搜索 - 找到了很多匹配项，例如 this 类似的问题，并检查了我能做的一切.甚至更多 - 我比较了两封电子邮件 - 由我的程序发送和由 Opera 发送，我无法推断出差异.但是 Opera 发送的内容被正确解释，但我的程序发送的内容却没有.我的程序发送的内容由一组其他邮件客户端正确解释，但 Outlook 无法正确解释.

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

这是一个示例消息(地址被替换，文件内容被裁剪，空行与实际消息中出现的完全一样，行数不超过 80 个字符):

<前>至:[e-mail]，[e-mail]主题:主题内容类型:多部分/混合；边界="------------边界"MIME 版本:1.0- - - - - - - 边界内容类型:文本/纯文本；字符集=utf-8"内容传输编码:base64这里是 Base64 编码的文本部分 - 它可能是本地化的，所以最好是UTF8它并做Base64- - - - - - - 边界Content-Disposition:附件；文件名=文件.jpg"内容类型:应用程序/八位字节流；名称=文件.jpg"内容传输编码:base64这里是 Base64 编码的文件数据- - - - - - - 边界

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

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

解决方案

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

<前>MIME 版本:1.0内容类型:多部分/混合；边界="------------边界"- - - - - - - 边界...- - - - - - - 边界...- - - - - - - 边界 -

更多阅读在这里:RFC1341/7.2 多部分内容类型>

I've written an SMTP client that sends e-mails with attachments. Everything's fine except that when an e-mail sent by my program is received by Outlook it displays two attachments - the file actually sent and a file with two characters CR and LF inside and this file has name ATT?????.txt.

I've done search - found a lot of matches like this for similar problems and checked everything I could. Even more - I compared two emails - sent by my program and sent by Opera and I can't deduce the difference. However what Opera sends is interpreted correctly, but what my program sends is not. What my program sends is interpreted by a set of other mail clients correctly, but not by Outlook.

I've telnet'et to the SMTP server, retrieved the two emails into a text file - one from my program, another from Opera, and compared them side-by-side. I didn't see any difference that could affect interpretation by an email client.

Here's a sample message (addresses substituted, file contents cropped, blank lines exactly as they appear in real messages, lines never exceed 80 characters):

To: [e-mail], [e-mail]
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

I tried to play with linebreaks after the last boundary - tried none, one, two, three, but this doesn't improve the situation.

Is there a set of some weird limitations that a mail client must follow to produce messages that are interpreted by Outlook correctly?

解决方案

The last boundary of a MIME part must be indicated by appending two dashes:

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

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

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

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

More reading here: RFC1341 / 7.2 The Multipart Content-Type

这篇关于在 Outlook 中收到电子邮件时的 ATTnnnnn.txt 附件的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！