Bug 74280 - signatures not PGP/MIME RFC 3156-compliant
Summary: signatures not PGP/MIME RFC 3156-compliant
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: evolution
Version: 7.3
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Jeremy Katz
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2002-09-19 14:04 UTC by Michael Schwendt
Modified: 2008-05-01 15:38 UTC (History)
0 users

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2002-09-19 14:05:33 UTC
Embargoed:


Attachments (Terms of Use)
example message (1.67 KB, application/x-gzip)
2002-09-19 14:05 UTC, Michael Schwendt
no flags Details

Description Michael Schwendt 2002-09-19 14:04:40 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020827

Description of problem:
On valhalla-list I've noticed that Evolution creates PGP/MIME signatures (aka
"detached signatures") which do not verify as GOOD in other mail user agents
such as Mutt or Sylpheed.

I've tracked this down to a bug in Sylpheed, but also a bug in Evolution. The
bugs in Sylpheed have been fixed in CVS. Several of Evolution's detached
signatures now verify fine with Sylpheed. Remains a signed message created with
Evolution 1.0.3 which does not verify as GOOD in either Mutt or Sylpheed.
Whether a new version of Evolution behaves different, I don't know
(bugzilla.ximian.com is time-consuming).

In particular, Evolution 1.0.3 applies content transfer encoding "8bit" to
content type "text/plain", which is not RFC 3156-compliant IMO. It should use
either Base64 or Quoted-Printable (which it converts to when it verifies the
signature itself).

Version-Release number of selected component (if applicable):
1.0.3-6

Comment 1 Michael Schwendt 2002-09-19 14:05:27 UTC
Created attachment 76604 [details]
example message

Comment 2 Michael Schwendt 2002-09-20 18:16:44 UTC
Hmmm, probably false alarm. In the message archive the same message is
quoted-printable encoded. I'll reopen this bug report when I can be sure that no
mail server has invalidated the signature by changing the content transfer
encoding of the signed message part to "8bit". Somewhere it got converted to
8-bit, and I have no idea where. The headers don't give a clue either. Other
messages with signatures are still QP here.



Note You need to log in before you can comment on or make changes to this bug.