ATTnnnnn.txt attachments when e-mail is received i

问题:

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?

回答1:

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