Attachment Warnings - End of Line Behavior Changed (CR, LF)

Michael H. Warfield mhw at WittsEnd.com
Thu Feb 2 18:14:53 GMT 2006


On Thu, 2006-02-02 at 15:28 +0000, Greg Matthews wrote:
> On Wed, 2006-02-01 at 20:58 -0500, Michael H. Warfield wrote:
> > 	Turns out it's far worse than we imagined.  ...<SNIP>...  Work in progress...
> > 
> > 	ITMT...  Turn off "Sign Clean Messages".
> > 

> yeegads! theres no way I can turn this option off now that it is
> implemented. I was hoping to upgrade MS from 4.45.4 to 4.50.x pretty
> soon, looks like this will have to be on hold for a while.

	Then you will have to suffer with the line ending problem and broken
S/MIME and GPG/MIME cryptographic signatures until it's fixed.  Pick
your poison.  You don't get both.  I don't have that option.  My
signatures HAVE TO WORK.

> Will the fix be announced here or will I have to monitor a perl mailing
> list somewhere?

	Nope...  It's gonna have to be a MailScanner fix.  Even when we altered
MIME::Tools to return CR/LF, something higher up on the food chain
stripped them.  That's one problem and specific to this thread.  But
merely fixing that doesn't fix the rest of the problem.

	The other problem is in reformating the Mime parts.  That's breaking
PGP and S/MIME signatures.

	For example Evolution will format a simple line with a hard return with
just that, a hard return (CR/LF), in quoted-printable, and then sign it
with GPG.

	That same line, when it re-encoded by the perl MIME encode_qp routine
comes out with the sequence =0A= at the end of each hard line ending.
That translates back as a hard return followed by a soft quoted
(escaped) return.  It does the same thing.  Both will decode back to the
same text.  But it breaks the signatures, because it's the encoded text
which is signed.  The trouble is, there is no fix for the perl code.
It's sloppy (excessive encoding) but not necessarily wrong either.  And
if you fix it to go the other way, you're broken when the message was
encoded by something else using sloppy encoding.  Damn if you do and
damned if you don't.  The only solution is to preserve the encoded text
and restore it exactly, if no modifications are made.  That's got to be
handled at a high level in MailScanner and it's not going to be pretty.

	Quoted-printable is ambiguous because there are multiple encodings
which can decode back to the same canonical text.  You have no
deterministic manner to reliably recover the original encoded text from
the canonical text in rebuilding the quoted-printable attachments.  So
you have no reliable way to rebuild the attachments from the canonical
text and preserve any cryptographic signatures.  Game over...

> G

	Mike

> > 	Mike
> -- 
> Greg Matthews           01491 692445
> Head of UNIX/Linux, iTSS Wallingford

	Mike
-- 
Michael H. Warfield (AI4NB) | (770) 985-6132 |  mhw at WittsEnd.com
   /\/\|=mhw=|\/\/          | (678) 463-0932 |  http://www.wittsend.com/mhw/
   NIC whois: MHW9          | An optimist believes we live in the best of all
 PGP Key: 0xDF1DD471        | possible worlds.  A pessimist is sure of it!

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 307 bytes
Desc: This is a digitally signed message part
Url : http://lists.mailscanner.info/pipermail/mailscanner/attachments/20060202/d9c9f1b2/attachment.bin


More information about the MailScanner mailing list