I’m the developer of GpgOL, Gpg4win’s Outlook extension. We provide a plugin to send PGP encrypted mails from Outlook.
It’s been reported to us that our Plugin does not create valid PGP/MIME mails when used with a Kopano Server. The report can be found in our ticket system: https://dev.gnupg.org/T3824
It would be interesting to hear if someone else using Outlook and Kopano could confirm that our Plugin does not create valid mails in such a setup. It’s free Software. download
Maybe our assumption that Kopano is to blame is wrong and there is something else broken in the setup of our reporter : -)
Just generate a Key and send yourself a “secured” mail with some text. If it looks weird and has stuff like “Content-type” in it you have confirmed the problem. It should look exactly as you have composed it.
Our Plugin relies on the MS-OXOSMIME MAPI to MIME conversion algorithm in Outlook/Exchange.
In short: If you create a Message with a special Message Class (for us: IPM.Note.InfoPathForm.GpgOL.SMIME.MultipartSigned ) Outlook treats the first (and only) attachment as the MIME structure of the mail.
So we build a valid multipart/signed or multipart/encrypted mime message and attach it, remove the body, set the message class and send it.
With SMTP Servers Outlook does the conversion but if it’s connected through Exchange the server does the conversion.
This somehow does not work with Kopano (at least we currently think so).
What happens is that our Attachment is split up and put into a Multipart/Mixed message. The “inline.txt” attachment contains the PGP/MIME version marker. The text/plain attachment contains the PGP content.
It looks like this:
Content-Type: multipart/mixed; boundary="=_oTgDbYJZJIkHstD84AzOsmjp4jFEt+cRHoHCd4sbXNjT-YqH" X-Mailer: Kopano 8.3.4-12 X-Original-Mailer: Microsoft Outlook 16.0 This is a multi-part message in MIME format. Your mail reader does not understand MIME message format. --=_oTgDbYJZJIkHstD84AzOsmjp4jFEt+cRHoHCd4sbXNjT-YqH Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable =2D----BEGIN PGP MESSAGE----- ...... =2D----END PGP MESSAGE----- --=_oTgDbYJZJIkHstD84AzOsmjp4jFEt+cRHoHCd4sbXNjT-YqH Content-Type: application/pgp-encrypted; name=inline.txt Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=inline.txt VmVyc2lvbjogMQ0K --=_oTgDbYJZJIkHstD84AzOsmjp4jFEt+cRHoHCd4sbXNjT-YqH--
While a valid PGP/MIME Message would be:
Content-Type: multipart/encrypted; protocol="application/pgp-encrypted"; boundary="=-=w4Rm8tvUXpODtB=-=" This is a multipart message in MIME format. --=-=w4Rm8tvUXpODtB=-= Content-Transfer-Encoding: 7bit Content-Type: application/pgp-encrypted Version: 1 --=-=w4Rm8tvUXpODtB=-= Content-Transfer-Encoding: 7bit Content-Type: application/octet-stream -----BEGIN PGP MESSAGE----- .... -----END PGP MESSAGE----- --=-=w4Rm8tvUXpODtB=-=--
Any Ideas where the MIME message is built / modified in your setup?
We could add some hacks to parse such a broken message but It would be better if we could really fix it so that we are able to send standard confirming PGP/MIME mails.
I would be happy to help analyzing and debugging this from our side, but I don’t have a Kopano setup.