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.