7

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?

Community
  • 1
  • 1
sharptooth
  • 167,383
  • 100
  • 513
  • 979
  • Can you post the exact message your SMTP client generates? I'm quite sure you made a mistake somewhere in the message headers. – Tomalak Mar 27 '09 at 16:26
  • Shouldn't there be a "--------------boundary--" at the end? (Note the two extra dashes) – Tomalak Mar 27 '09 at 17:23
  • 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 Mar 27 '09 at 17:38
  • Outlook simply sees an incorrect message ending and anticipates yet another attachment that actually isn't there. – Tomalak Mar 27 '09 at 17:41
  • Would you add a "mime" tag to that question? Thanks. :) – Tomalak Mar 27 '09 at 17:43
  • 1
    The most ironic thing is that I've read the RFC quite thoroughly but completely skipped the last boundary extra dashes part. – sharptooth Mar 27 '09 at 17:44
  • BTW, why did you remove the "language-agnostic" tag? – sharptooth Mar 27 '09 at 17:45
  • Because [language-agnostic] would mean "refers to a general algorithmic approach to a problem" - say "sort a list of values". It does not mean "not about programming in particular". Strictly speaking, this question is rather the latter category. – Tomalak Mar 27 '09 at 17:49

1 Answers1

13

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

Tomalak
  • 332,285
  • 67
  • 532
  • 628