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
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.
(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.
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.
(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.
I would like to see this patch to be included in the code. Would it be acceptable to create a (runtime) configuration option for the GPG plugin to allow the acceptance of this type of message? So that when someone could choose to use this code when the option is enabled and that is is disabled by default.
(In reply to stefan.ubbink from comment #5) > I would like to see this patch to be included in the code. The feature is acceptable, however the patch itself falls short and the patch author seems to have a strong aversion to improving the patch. In its current state, the patch will not be included.
Hmm... ignore comment #6, I thought I was commenting on a different bug item.