Apple Mail software added Carriage Return<0x0D> in a .txt file attachment before each CRLF pair

Hello MrHoffman,

I was trying to clarify the issue I'm facing that it was not specific to CSV files, nor it was related to how line feed was handled on macOS vs other systems even though those information would be helpful for someone encountered CSV file attachment related issues. I was not dealing with Excel or other Microsoft software at all.

When I discovered this problem I was just trying to send a plain txt file attachment as shown in my previous message. And the receiving party kept reporting MD5 mismatch on the file. My initial reaction was actually along the line of some line feed conversion issues across different systems.

But incidentally when I tried using other mail client (web mail interface) this issue did not happen, then I started looking into search Mail related issues and found at least there was one message thread related to this dated back to 2009 https://discussions.apple.com/thread/2235362 and there was no resolution in the end. In that thread, there were detailed discussions about the file attachment in the outgoing mail suggesting wrong handling by Mail which I'm not an expert in that area to comment on.

You brought up a very interesting point in your message that the mail server in the middle could be in the play. So I did a quick test by using my Yahoo email account to send a email with this mail-test.txt file attachment.

First I composed the email in Safari using Yahoo email web page interface, the downloaded mail-test.txt was exactly same as the original file. Then I used Apple Mail to compose the email with the same Yahoo email account (of course, the smtp/pops for the Yahoo account needs to be setup in Mail), but this time the downloaded file had the extra 0x0D in there. It appears this test still point to Mail had something to do with it.

Although it may not be conclusive as each email sent may hop through different servers, but so far all the text attachment emails (>10) sent via Mail all showed this issue. Other web mail clients (Gmail & Yahoo) I've tried (>10) with the same text file attachment would reach destination exactly the same.

Will you be able to do a quick test?

<I wish there is a way I can attach my mail-test.txt to the message which would make things much easier for the test>

1. Compose a text file with 3 lines.
2. Check it has 0x0D, 0x0A at the end of each line in a hex editor.
3. Send an email with this text file as an attachment to another email account.
4. Check the received file at the other email account whether you see extra blank lines in between/extra 0x0D in hex editor.

I'd like to find out if it is a real problem with Mail that can be replicated or some other factors cause this issue (such as the Mail version I'm using etc).

MrHoffman,

Thanks for your reply and sharing your experiences. I'm not sure why it was viewed as to be Microsoft Windows files related issue or CSV specific. At this point, it looks more to be an Apple Mail text file attachment issue.

Sure the workarounds you suggested would be fine for the short term although it forces users to go through extra steps that may not be desirable in the long run. It will be beneficial to understand the root cause and have Apple Mail fixed if it has been broken as documented in https://discussions.apple.com/thread/2235362

To isolate the problem further, I recreated the it without touching Windows or its file formats at all. From macOS terminal a mail-test2.txt was created using vi with 3 lines of text as below, each line was ended with LF 0x0A the unix style:

Sent as an attachment in Mail to my Gmail/Yahoo account, after downloaded an extra 0x0D showed up before each LF 0x0A. Although TextEdit would not show extra blank line since there were no double 0x0D before LF 0x0A.

The same mail-test2.txt was sent by Gmail as an attachment, it was received exactly as the original file without any alteration.

I don't think it is too much to ask Apple Mail be capable sending a text file attachment without modification so the receiving end would get the original content just like many other mail clients are capable of.

Thanks for your reply and data points.

However, the problem I've traced is not specific to CSV files but in general with any text files. And it is not about how unix vs windows handles the new line differently. The point is Mail should send text file attachment following the standard (whatever that maybe), when a mail client (following the same standard) should be able to retrieve the attached text file exactly as the original file.

The issue was that Mail somehow added an 0x0D before each 0x0D 0x0A(=CR/LF) pair in the text file as an attachment when it reaches other mail systems. Below is a mail-test.txt file I had

When I received this file attachment on Gmail or Yahoo mail, the downloaded file became:

You can see the extra line in the text display and the extra 0x0D (red arrow place) in the hex dump for each line.

I've used other mail client software to send the same text file as an attachment, the downloaded file was exactly the same as the original text file (no extra 0x0D).

Below is the hex dump of the original mail-test.txt as I don't see an attach file option here. If any one of you can do a simple test to see if the problem can be duplicated, that would be great. Please use the .txt as the attached file extension as Mail may handle other file type differently.

40 31 30 30 30 0D 0A 30 30 20 30 31 20 0D 0A 71 0D 0A