Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I’m sending a file via email from a Mac (Snow Leopard) to another Mac (Lion).

It turns out that all the line feeds (0x0A) in the file transform into carriage returns (0x0D), effectively turning the original file into a completely different file.

Any ideas why something like this would take place?

This does not happen when the sender upload the file to the web, and the recipient then downloads the file using his web browser. It also doesn’t happen if the sender first ZIPs the file and sends it via email; the recipient gets the original file intact after unzipping the ZIP file. Is there something special about email transfers I should know about?

share|improve this question
Do you send the file as an attachment or do you just copy and paste? – Dennis Dec 1 '11 at 14:29
I'm sending it as an attachment. – Enchilada Dec 1 '11 at 15:24
Remember that early (pre-OSX) Macs used CR as the line terminator. There might be some sort of sneaky conversion happening (although I have no idea where exactly). – grawity Dec 4 '11 at 20:51
Which mail client are you using ? Have you tried Thunderbird ? – harrymc Dec 5 '11 at 9:59
I'm not sure what mail client the Lion user is using. Anyway, it's not really my issue. I'm just trying to understand why something like this would take place. (See also my reply to @Ravachol's answer below.) – Enchilada Dec 5 '11 at 17:31
up vote 2 down vote accepted

There is nothing special about email transfers that you should know about.

The normal function of an email-client when transmitting the file is to transmit as-is. The encoding of the file using base64 or anything else should not imply any change to the contents of the file.

Evidently, your email-client is over-doing its job. It not only analyzed the file and decided that it contains text, it also took it upon itself to normalize the end-of-lines. Unfortunately, it is botching the job.

According to Wikipedia, carriage-return is a Newline character for Mac OS up to version 9. It certainly should not be the case for Snow Leopard.

Not being on a Mac, I cannot test anything. And as I don't know which email-client is being used, I cannot google for the problem. So I suggest that you look into that unknown email-client's settings and try to find some compatibility option with OS-9 that got turned on by mistake, or some other setting for transmitting files as-is.

share|improve this answer

SMTP RFC2821, Section 2.3.7 (found here) states the following:

SMTP commands and, unless altered by a service extension, message data, are transmitted in "lines". Lines consist of zero or more data characters terminated by the sequence ASCII character "CR" (hex value 0D) followed immediately by ASCII character "LF" (hex value 0A).

So your MUA MUST convert them before sending through the SMTP server. Remember SMTP was designed for text data, and is therefore not binary compatible (see base64 encoding for more information on sending binary data)

share|improve this answer
The attachment file I sent was indeed base64 encoded. However, after every 64 bytes there was a line feed (0x0A), which represents a newline on Mac OS X. The question still is: Why did 0x0A transform into 0x0D, leaving the total byte size of the file intact? I still don't quite get that... – Enchilada Dec 1 '11 at 15:27
The line-feed every 64 bytes is normal and can be ignored, as it has no function except making the base64 more readable. – harrymc Dec 6 '11 at 16:28

Either zip, tar, gzip, bzip, or some combination of those before sending the file, or find another email client. Clearly the one you're using is doing too much work.

share|improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .