GNOME Bugzilla – Bug 214915
GPG Signatures are displayed as "BAD" when indeed they are good
Last modified: 2002-04-26 18:05:19 UTC
Since I use to sign my outgoing messages, from time to time I encounter messages (up to know only messages I sent to mailing lists) that are displayed as having a bad signature. Apparently the message gets sent out with no encoding information, but evolution adds "charset=us-ascii" before passing it to gpg : --- 8< --- nils@cognac:~> diff -u bochum/mutt-bochum-28267-1 gpg.in --- bochum/mutt-bochum-28267-1 Fri Nov 9 14:59:50 2001 +++ gpg.in Fri Nov 9 14:55:08 2001 @@ -1,5 +1,5 @@ -Content-Type: text/plain Content-Transfer-Encoding: quoted-printable +Content-Type: text/plain; charset=us-ascii On Fri, 2001-11-09 at 14:05, Michael Schwendt wrote: > On 2001-11-09, Martin Sprenger wrote: --- 8< --- "bochum/mutt-bochum-28267-1" is what mutt feeded to gpg (it verifies the signature as good BTW) and "gpg.in" is what evolution feeded to gpg. Both were operating on the same mailspool, the only difference being that mutt accessed the file directly and evolution goes over imap/ssl. When accessing the IMAP server directly (telnet over SSL tunnel), there is no "charset=us-ascii" directive, so I blame evolution for not leaving the message untouched :-).
if the message was big enough, we'd have downloaded it in parts instead of 1 lump sum. Therefor it is entirely possible that the server told us the part was us-ascii in the BODYSTRUCTURE command.
We don't use bodystructure that way. (It's possible that the IMAP server added the charset= thing itself anyway, but unlikely. Sounds more like something camel would do.)
except that camel doesn't set a charset parameter when parsing or when writing it out, you have to set it explicitly and I *know* we aren't doing that.
btw, zucchi and I had debated doing this when we were writing code to auto-detect the charset of mime parts that didn't have one but decided against it for this very reason.
The IMAP server definitely didn't add the charset blurb to the message. I telnetted to the IMAP server and checked it by my self (the body was exactly the same as what mutt served to gpg). It seems that evolution "somewhere" (I don't blame a specific part) messes with the header -- note that the "Content-Type" line appears before "Content-Transfer-Encoding" in the original and after that in the body evolution fed to gpg.
try BODYSTRUCTURE I'm 100% certain that either the server sent us wrong info or we misinterpreted data sent from the server (ie it sent us a NIL which we interpreted as "us-ascii" or something) oh hell, I want the entire IMAP log.
boilerplate for you, nils: If you want to help debug the problem, you can get information on the conversation between evolution and your server by following the instructions here: http://support.ximian.com/cgi-bin/ximian.cfg/php/enduser/std_adp.php?p_sid=TImixkWf&p_lva=&p_refno=010813-000000 Without that information, we are unlikely to be able to solve the problem.
Mass close of stale bugs >= 4 months old. Odds are that the reason that the user's have not responded are because the issues have been fixed in more recent releases of Evolution. If your issue is still not resolved in Evolution 1.0.4, please reopen and try to provide any additional information that was requested. Thank you.
Hm, evolution (1.0.3) still messes with the signed data before feeding it to gpg. Here's a diff between the mime part that mutt saved and what evolution shows (and what I think passes to gpg) -- fgh1 is evolution, fgh2 is mutt's send-mail: --- fgh1 Fri Apr 26 18:07:45 2002 +++ fgh2 Fri Apr 26 18:12:53 2002 @@ -8,8 +8,7 @@ --=20 Nils Philippsen / Berliner Stra=DFe 39 / D-71229 Leonberg // +49.7152.2096= 47 -nils@wombat.dialup.fht-esslingen.de / nils@redhat.de / nils@fht-esslingen.d= -e +nils@wombat.dialup.fht-esslingen.de / nils@redhat.de / nils@fht-esslingen.de Ever noticed that common sense isn't really all that common? --Q68bSM7Ycu6FN28Q
Argh, bugzilla messed it up again, attaching the diff instead.
Created attachment 41168 [details] [review] Diff between evolution's mime part and what is in mutt's sent-mail
*** This bug has been marked as a duplicate of 217540 ***