Hi John Jack Doe! Am 05.03.19 19:08 schrieb(en) JohnJackDoe tele2 de:
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.
Attachment:
pgpOxARk326Sz.pgp
Description: PGP signature