\n replaced with \r\n when decoding decrypted text content on Linux

[Peperud]

Perhaps related to the canonization mentioned in #436

On Linux:

1. Message body is created by encrypting a MimePart, created from a Linux text file (\n line endings).
2. After decrypting the message and writing the content to a file, it appears that Linux \n are replaced with \r\n, thus resulting in a file that is binary different from the original.

I can see how, if the initial text encoding requires canonization (?), on the receiving/decryption end there might be no way to know if the \r's were added or were in the original content to begin with.

However an argument can be made that when decoding text content, the decoder should use OS appropriate line endings. Either as default behavior or option controlled.

P.S. I'm after s/mime and haven't tried if it's the same with text files without encryption.

[jstedfast]

Unfortunately passing the decrypted content through a \r\n -> \n converter can also corrupt the content if, for example, the content is binary.

Now, MimeKit could parse the decrypted MIME, then re-serialize it using the OS-specific newline format, and then parse it back again... but that's a lot of processing.

Perhaps a simpler solution is to just canonicalize TextPart's logic that reads the content into a string.

[jstedfast]

I think that I'll be ready to make a new release (2.0.7) this coming weekend, so this will be included in that nuget release when it happens.

[Peperud]

Thanks!
So it is going to be always on for text/plain? No "don't mess with the line endings" opt out?

[jstedfast]

It'll always canonicalize all text/* parts to the OS's line ending format.

I think that makes more sense than having overrides.