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?

  • 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). – user1686 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

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.


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)

  • 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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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