MultipartSigned forces body ContentTransferEncoding for non-binary content

[haboustak]

Part of my project (NHIN Direct) involves sending signed and encrypted MultipartReport content (RFC 3462). I am having some trouble with the ContentTransferEncoding of the parts within the MultipartReport after sending.

RFC 3462 says that 7-bit encoding should be sufficient, and so I'm trying to use 7-bit, but MultipartSigned.PrepareEntityForSigning is forcing it to either Base64 or QuotedPrintable.

I don't understand the motivation behind using those two encodings when signing, but I don't think that QuotedPrintable is required if the source content is not binary.

[jstedfast]

The reason I encode all non-Base64 parts using Quoted-Printable is because text lines starting with "From " may get munged in transport (or at delivery) on Unix-based mail systems that use the mbox format. RFC 3156 mentions this (I know RFC 3156 is for OpenPGP/MIME, but the same problem applies to S/MIME as well).

The PrepareEntityForSigning() could be smarter about this by using the MimePart.GetBestEncoding (EncodingConstraint.SevenBit) which will auto-detect whether or not any content lines begin with "From ".

Fixed in git master (I am just about to roll a 0.18 release)