Re: [Patch] fix broken decryption of s/mime messages loaded from imap

Albrecht Dreß <[email protected]> Wed, 06 Mar 2019 19:52:11 +0100
Newsgroups	gmane.comp.gnome.apps.balsa
Message-ID	<[email protected]>
Hi John Jack Doe!

Am 05.03.19 19:08 schrieb(en) [email protected]:
> You won the bet. It's M$ Exchange. I owe you a beer or two.

😊️

> I did some tests and sent a test message with an attachment and autokey via the M$ Exchange server to myself and to my other private email account. Both were received and decrypted without any problems.

Hmmm, ok.

> I did some internet search and found no confirmation that M$ Exchange and/or Outlook can handle PGP/MIME iaw RFC 3156.

For Lookout, a plug-in is available (Gpg4Win, <https://www.gpg4win.de/>, the development has been sponsored by the German government, Federal Office for Information Security (BSI), btw.).  As always, such OL plug-ins may or may not work well, as M$ tends to change internal structures and api's without notice.  I.e. it might simply stop working after the next update.

> However, I found some information that M$ Exchange is rewriting the content header and thus causing decryption trouble.

This has, at least in the past, been a problem – as exchange is basically a database frontend, IIRC it just re-wrote “unknown” headers to application/octet-stream.  I no *no* deep insight into Exchange, though, so I cannot tell if it's still an issue.

> I also asked the IT specialist of the company I work for if M$ Exchange and/or Outlook can handle PGP/MIME iaw RFC 3156. He answered that M$ Exchange doesn't care about the content and Out is downloading everything that is offered. For M$ Exchange he might be right.

I'm not absolutely sure…  I remember a case (~1 year ago) where the signatures of messages created by a (defective) python lib were broken: the python lib erroneously added “MIME-Version: 1.0” to /every/ part, not only to the top-level headers.  Exchange apparently stripped them in the database, re-assembled the message without them, which of course broke the signature…  However, at least /decrypting/ messages should work just fine.

> See the headers from my testing below. With Outlook I'm not sure because I received an message that was retrieved with Outlook and resent to myself. And in this message the header was rewritten and the pgp part was base 64 encoded. I will do some more testing.
> 
> Here are parts of the header of the email sent with Balsa to the M$ Exchange server:

Running all three snippets through a three-way diff shows that they are identical, with the exception of the extra “X-*” top-level headers which are absolutely legal and should /not/ hamper decryption in any way.  Which of these messages does Balsa decrypt, and which not?  Which one has been received from the IMAP server?

I also double-checked with the current git master that GnuPG decryption of multipart/encrypted *does* work just fine for messages loaded from IMAP – with dovecot at work, and with two different ISP's (vodafone/arcor and netcologne; not sure which IMAP server they use, though).

It /might/ be helpful to run Balsa with GpgME debugging, as it /might/ give more error information when the decryption process failed which is not passed through gpgme (see <https://www.gnupg.org/documentation/manuals/gpgme/Debugging.html>):

* terminate balsa;
* run (from the shell) “GPGME_DEBUG=9:/your/home/balsa-gpgme.log /path/to/balsa”
* open *one* message where decryption fails, then terminate Balsa
* check balsa-gpgme.log

Cheers,
Albrecht.

_______________________________________________
balsa-list mailing list
[email protected]
https://mail.gnome.org/mailman/listinfo/balsa-list
signature.asc (application/pgp-signature, 488 B)