ATTnnnnn.txt attachments when e-mail is received in Outlook

7
votes

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: [email protected], [email protected]
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
emailoutlooksmtpmime
Can you post the exact message your SMTP client generates? I'm quite sure you made a mistake somewhere in the message headers. – Tomalak
Shouldn't there be a "--------------boundary--" at the end? (Note the two extra dashes) – Tomalak
Yes, yes, it is the extra two dashes in the end!!! I've never read of this in any documents and it's a complete surprise to me. – sharptooth
Outlook simply sees an incorrect message ending and anticipates yet another attachment that actually isn't there. – Tomalak
The most ironic thing is that I've read the RFC quite thoroughly but completely skipped the last boundary extra dashes part. – sharptooth

1 Answers

13
votes

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