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!
Attachment:
signature.asc
Description: This is a digitally signed message part