Ok all, I'm cross posting this to both Evolution and MailScanner because I can already predict the finger pointing that's naturally going to result. A few months ago, someone brought it to my attention that my GPG signatures (messages signed only, not encrypted) where suddenly turning up "bad". The signature on this message will probably be "bad". It took some major head scratching to figure out what changed, what the parameters where, and what the hell was happening but I think I've got in narrowed down to some poor behavior on the part of BOTH Evolution AND MailScanner (or a component of MailScanner - not sure). It seems to have initially broken with an upgrade to MailScanner. I think upgrading to 4.47.4-2 or there abouts might have been the triggering event, but I don't remember what I was running on that server prior to that. Before then, all my signatures GPG signatures were good. After, they were bad. If I turn off MailScanner on my server, the signatures are good. I have accounts on several servers and the signatures are bad if I forward mail through one running a recent version of MailScanner. I just upgraded one of my servers to 4.50.5-12 and now I've got bad signatures through that server as well (I wasn't running MailScanner on that one before). But, that doesn't get Evolution off the hook. It's only happening for messages that I'm composing in Evolution! If I compose them in Mutt or vi a text file and send it, everything is fine. Also, my saved copies in the Evolution sent box is fine. Sooo... I compare what was saved in the "sent" box with what was received with a bad signature... What was the difference? Carriage Returns! Evolution is terminating lines with CR-LF when composing a message. MailScanner is removing the CR and leaving the LF. Apparently, Evolution called gpg in binary mode to create the signature. Modifying even the line termination then breaks the signature. No other mailer I use generates the DOS/Windows line termination, they all end lines with *NIX convention of LF only (no I haven't tried ThunderBird or KMail or other GUI client as yet). 1) Why must we be adding extraneous CR on text messages? Is this REALLY necessary? 2) Why is MailScanner reformating my messages and stripping the CR's? That's not merely appending a "scanned by". That's modifying the body of the messages itself. Now, maybe it's the way MailScanner is parsing and reassembling the Mime parts, I don't know there. But it should not do ANYTHING that's going to break a signature. That's verboden. 3) Why is GPG signing the message in text mode instead of binary mode? We can go round and round on the merits and demerits of that and get nowhere. Looking at my .muttrc file, Mutt uses "--textmode --clearsign" when generating PGP/Mime signed attachments or old style signed text message. If you think it should be signed in text mode, that still recurses back to an Evolution problem and the parameters that it's calling gpg with, so it's not a gpg problem. Unlike Mutt, I don't see any way to alter the gpg calling parameters in Evolution (ignoring the fact that it should just work out of the box). I would argue that BOTH packages are doing something wrong here. I don't think we should have this extra CR cruft on text but I don't think MailScanner should be stripping it off legitimate clean messages either. Maybe gpg should be clearsigning in text mode as well. All I know is that this combination does NOT work. Fixing any of the three points would fix the immediate breakage, but, maybe, we should fix all three points and really fix it, least it come back and bite us in the ass from another direction? Sooo... Can we have some discussion and comments about how to fix this thing so GPG signatures can work with this combination? Regards, Mike -- Michael H. Warfield (AI4NB) | (770) 985-6132 | mhw 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!
Description: This is a digitally signed message part