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

问题描述

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

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

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

这是一个示例消息（地址替换，裁剪文件内容，完全按照它们出现的空白行真实消息，行不超过80个字符）：

 
 To：[e-mail]，[e-mail] 
主题：subject 
 Content-Type：multipart / mixed; border =------------ boundary
 MIME版本：1.0 
 
 --------------边界
 Content-Type：text / plain; charset =utf-8
内容传输编码：base64 
 
这里是Base64编码的文本部分 - 它可能是本地化的，所以
最好是UTF8它和做Base64 
 
 -------------- boundary 
 Content-Disposition：attachment; filename =file.jpg
 Content-Type：application / octet-stream; name =file.jpg
 Content-Transfer-Encoding：base64 
 
这里是Base64编码的文件数据
 
 --------- -----边界
 
 

我试图在最后一个边界之后玩linebreaks - 尝试没有，一个，两个，三，但是这并没有改善这种情况。

邮件客户端是否有一些奇怪的限制，以产生由Outlook解释的邮件？

解决方案

MIME部分的最后一个边界必须附加两条破折号：

 
 MIME版本：1.0 
内容类型：multipart / mixed; boundary =------------ boundary
 
 -------------- boundary 
 ... 
 
 --------------边界
 ... 
 
 --------------边界 -  
 

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

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屋！