After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 215787 - Evolution says that otherwise good signatures are invalid
Evolution says that otherwise good signatures are invalid
Status: RESOLVED FIXED
Product: evolution
Classification: Applications
Component: Mailer
pre-1.5 (obsolete)
Other All
: Normal major
: Future
Assigned To: evolution-mail-maintainers
Evolution QA team
: 215972 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2001-11-20 23:07 UTC by Elliot Glaysher
Modified: 2002-02-28 02:29 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Message saved from evolution (1.87 KB, text/plain)
2001-11-20 23:07 UTC, Elliot Glaysher
Details
Output from mutt (1.82 KB, text/plain)
2001-11-20 23:08 UTC, Elliot Glaysher
Details
My public key for your convenience (2.61 KB, text/plain)
2001-11-20 23:09 UTC, Elliot Glaysher
Details
This message was sent from evolution, but evolution doesn't verify it correctly. Mutt does. (6.25 KB, text/plain)
2002-01-26 23:02 UTC, Elliot Glaysher
Details

Description Elliot Glaysher 2001-11-20 23:07:03 UTC
Looking through my sent-mail (FYI, stored on a local IMAP server),
evolution reports that about 1/3 of all the signed outgoing mail (read: all
non-encrypted mail) have bad signatures. These are messages sent from
evolution, so I was a little worried.

This seemed strange to me, so I opened up the same messages with mutt,
which verified the signatures as legit. So these messages are getting
signed correctly, but aren't being read correctly.

While I can't consistently reproduce this behaviour, I can offer you saved
copies of the messages from both evolution and mutt. mutt can't verify the
signatures on mail exported from evolution.

Looking over the messages, it appears that evolution has stripped all
glyphs from the email, and is trying to verify THAT, while mutt tries to
verify the message with the glyphs intact.

Attached are the messages from both evolution and mutt.
Comment 1 Elliot Glaysher 2001-11-20 23:07:35 UTC
Created attachment 40694 [details]
Message saved from evolution
Comment 2 Elliot Glaysher 2001-11-20 23:08:06 UTC
Created attachment 40695 [details]
Output from mutt
Comment 3 Elliot Glaysher 2001-11-20 23:09:11 UTC
Created attachment 40696 [details]
My public key for your convenience
Comment 4 Jeffrey Stedfast 2001-11-20 23:12:44 UTC
the first one fails because it should be Content-Transfer-Encoding:
quoted-printable, 8bit is forbidden.

the second one fails because of the way it qp encoded the message.

this can't be fixed.
Comment 5 Elliot Glaysher 2001-11-20 23:56:32 UTC
> the first one fails because it should be Content-Transfer-Encoding:
> quoted-printable, 8bit is forbidden.

That's nice. Evolution generated that message. So there's a bug
somewhere, but possibly not here.

> the second one fails because of the way it qp encoded the message.

The second one *doesn't* fail. At least not with mutt. The first one
fails in both clients, due to mangling by evolution. The whole point
of me including two copies of the same message was to show how two
different clients handled the email.

The second one is what's stored in the IMAP mailbox, and what mutt
generated orriginally. If I understand correctly, this means that
evolution is recieving the message from the IMAP server exactly as
stated in the second message, and evolution is generating the illegal
"Content-Transfer-Encoding: quoted-printable, 8bit" from the qp
message. I'm not sure if mutt's qp encoding is illegal or not. 

Further investigation: the second message is what's stored in
evolution's IMAP cache. It's a byte for byte copy, with the exception
of an incomplete XMailer header.

Short story: the second message is valid. The first message, which you
say is illegal, was generated by evolution from the second message. If
the second message (which is valid) is stored in evolution's IMAP
cache, (assuming that evolution works the way I think it does) why
can't this be fixed by sending the version kept in the IMAP cache to
gpg, instead of the mangled output?
Comment 6 Jeffrey Stedfast 2001-11-21 00:08:30 UTC
no, evolution did not generate that message...mutt did:

User-Agent: Mutt/1.3.23i

Comment 7 Elliot Glaysher 2001-11-21 00:15:32 UTC
> no, evolution did not generate that message...mutt did:
> User-Agent: Mutt/1.3.23i

No, mutt sent the orriginal message. (the second attachment)

Like I stated in my last reply, evolution generated the first from the
second.

Under your logic, if I send a message with mutt and then save the
message with evolution, then the user agent line should be
"User-Agent: Evolution/0.99.x"
Comment 8 Jeffrey Stedfast 2001-11-21 00:22:14 UTC
what are you talking about?

both messages claim to have been written (ie they have a UserAgent
header) that says mutt.

neither say Evolution composed the message.

I think you are seriously confused.
Comment 9 Jeffrey Stedfast 2001-11-21 00:28:56 UTC
okay, I think I understand what you are saying now. So the first
message was composed in mutt and sent to Evolution, at which point you
then saved the message to it's own file?

if that's the case, no wonder it has a transfer encoding of 8bit...
when exporting messages, evolution decodes all 8bit parts to 8bit from
QP or Base64.

it does *not*, however, use that data representation to verify the
signature. It feeds it to gpg as QP encoded data.
Comment 10 Elliot Glaysher 2001-11-21 00:48:26 UTC
> okay, I think I understand what you are saying now. So the first
> message was composed in mutt and sent to Evolution, at which point 
> you then saved the message to it's own file?

yes. exactly. I though I made this clear by naming the file "Message
saved from evolution". Sorry this wasn't clear before. 

I *was* wrong in my first description, saying that evolution had sent
them, though. This should probably be renamed to something like
"Evolution can't verify signatures made by mutt."

> if that's the case, no wonder it has a transfer encoding of 8bit...
> when exporting messages, evolution decodes all 8bit parts to 8bit 
> from QP or Base64.
> it does *not*, however, use that data representation to verify the
> signature. It feeds it to gpg as QP encoded data.

This means my assumption on what the problem was was totally wrong.

Let's start over. Totally. First, consider attachment 40694 [details] (Message
saved from evolution) totally removed from the conversation now. There
is only one attachment: 970 (Output from mutt), which is the message
as is on the IMAP server.

When verifying the signature of this message in evolution, GnuPG
returns the state BAD SIGNATURE.

When verifying the signature in mutt, GnuPG verifies the signature as
a good one.

Okay, then the question becomes why can mutt verify the signature
while evolution can't, if they're both feeding the same message to GnuPG? 
Comment 11 Luis Villa 2001-12-18 04:58:44 UTC
Reopening; the basic question is still not answered- why does it
verify in mutt and not evo?
Comment 12 Elliot Glaysher 2002-01-26 23:00:13 UTC
Well, As of the 1.0.1 release, I'm now getting messages sent *from*
evolution (X-Mailer: Evolution/1.0 (Preview Release)), that aren't
verifying in evolution 1.0.1,

These messages verify correctly in mutt.

The next attached message is pulled from the actual mbox file on the
imap server, and verifies as a good signiture in mutt. As stated
above, evolution thinks it's a bad signiture.
Comment 13 Elliot Glaysher 2002-01-26 23:02:15 UTC
Created attachment 40977 [details]
This message was sent from evolution, but evolution doesn't verify it correctly. Mutt does.
Comment 14 Jeffrey Stedfast 2002-02-27 20:11:22 UTC
*** bug 215972 has been marked as a duplicate of this bug. ***
Comment 15 Jeffrey Stedfast 2002-02-28 02:29:41 UTC
I just fixed this in cvs along with updating the code to comply with
rfc3156 rather than rfc2015.

verified my fixes with your sample message, if you could upgrade to
cvs HEAD and keep me posted on how well it works out for you, that
would be great.