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: user1@host.com, user2@host.com 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:
More reading here: RFC1341 / 7.2 The Multipart Content-Type