Bug 3632 - Parse PGP/MIME headers emitted by GPGMail + Exchange
Summary: Parse PGP/MIME headers emitted by GPGMail + Exchange
Status: NEW
Alias: None
Product: Claws Mail
Classification: Unclassified
Component: Plugins (show other bugs)
Version: 3.14.0
Hardware: PC All
: P3 enhancement
Assignee: users
URL:
Depends on:
Blocks:
 
Reported: 2016-04-03 19:00 CEST by Michael Gmelin
Modified: 2016-07-12 15:05 CEST (History)
0 users

See Also:


Attachments
Read exchange butchered email, suitable for use with "git am" (3.75 KB, patch)
2016-04-03 19:00 CEST, Michael Gmelin
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Gmelin 2016-04-03 19:00:22 CEST
Created attachment 1640 [details]
Read exchange butchered email, suitable for use with "git am"

Exchange always wants to have at least one message part it understands, so it inserts an empty email text/plain attachment into the message, leading to three parts instead of two. It also changes the mime type of the container from "encrypted" to "mixed".

The attached patch solves this problems and allows decryption of such email (signature checking works as well).

multipart/mixed
  text/plain (length:0)
  application/pgp-encrypted
  application/octet-stream

instead of the usual:

multipart/encrypted (protocol="application/pgp-encrypted")
  application/pgp-encrypted
  application/octet-stream
Comment 1 Andrej Kacian 2016-05-15 19:03:52 CEST
What you describe is against the relevant RFCs (2015, 3156, sections 4 and 5 in each). I do not think we should encourage this.

I know that the common advice is "be strict with what you send, be accepting with what you receive", but I feel that is for situations where there are ambiguities in the standard. This is a pretty clear-cut violation of the RFCs.
Comment 2 Michael Gmelin 2016-05-15 19:18:08 CEST
(In reply to comment #1)
> What you describe is against the relevant RFCs (2015, 3156, sections 4 and 5
> in each). I do not think we should encourage this.
> 
> I know that the common advice is "be strict with what you send, be accepting
> with what you receive", but I feel that is for situations where there are
> ambiguities in the standard. This is a pretty clear-cut violation of the
> RFCs.

I agree that we shouldn't encourage this, but unfortunately other clients like Mail.app and Thunderbird can open, decrypt and verify those e-mails without any issues. Mutt might as well, didn't test it myself. So there is little incentive for anyone to correct the source of the problem.

I prefer to encourage people to use encryption over trying to persuade commercial vendors into fixing their various RFC violations.
Comment 3 Andrej Kacian 2016-05-16 15:11:42 CEST
Well, you're welcome to use the patch yourself, as well as convince any distribution packagers to include the patch, if you feel that is the right thing to do. Or, you can request the relevant RFC to be updated, relaxing the rules about the message structure.
Comment 4 Michael Gmelin 2016-05-16 16:45:19 CEST
(In reply to comment #3)
> Well, you're welcome to use the patch yourself, as well as convince any
> distribution packagers to include the patch, if you feel that is the right
> thing to do. Or, you can request the relevant RFC to be updated, relaxing
> the rules about the message structure.

That's great news, thank you!

But seriously, maybe a more general approach to solve such problems would be helpful? Something like an input filter plugin that can modify the mime structure of a message (maybe even by configuration?) before it is fed into the message view.