Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

I'm sending a simple mail on Windows XP with 4 attachments:

  • dummy.txt (end of line: CRLF)
  • dummy.xml (end of line: CRLF)
  • dummyjustlf.txt (end of line: LF)
  • dummyjustlf.xml (end of line: LF)

According to the client I'm sending the mail with the line endings change:

  • Outlook '07: EOL's are unchanged
  • Thunderbird 3: EOL of dummyjustlf.txt is changed to CRLF, others are unchanged
  • Java Mail: EOL of dummyjustlf.txt and dummyjustlf.xml changed to CRLF, others are unchanged

How is this behaviour specified? Are there RFC's documenting this? Does the client decide how to send or how to receive the mail with the attachments and convert the EOL the way he wants?

share|improve this question

1 Answer 1

up vote 3 down vote accepted

Its probably a combination of the email client and platform you are running on.

Ideally, attachments should always stay the same, and if the files were binary (or put in a binary container, such as .zip) there wouldn't be a problem.

What I suspect is happening is the client application is inserting the plaintext messages as attachments with "quoted printable" encoding rather than Base64 (that binary files get encoded as). To check this, you need to view the raw message data in the receiving email app:

  • In Gmail this is "Show Original" in the menu next to the top-right Reply button.
  • In Thunderbird, View -> Message Source
  • There are probably equivalents in Outlook and Java mail.

You need to look for the attachments, which start with headers like:

--0016e65c71b2a252eb04a3a1f642
Content-Type: text/plain; charset=US-ASCII; name="test.txt"
Content-Disposition: attachment; filename="test.txt"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_gnvt3nlf0

If "Content-Transfer-Encoding" is something other than "base64" (such as "quoted-printable"), and you can see the textual content of the text files below, then that is likely the source of error, as the line endings are probably normalised by the sending app when the message is sent (most emails are sent as plaintext).

Base64 encoding converts binary files to plaintext which can sent by the sender and converted back to binary again at the receiver, and dont get mangled in the plaintext driven world of email. This is probably what Outlook is doing for all attachments, and what TB is doing for the .xml files.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.