Page MenuHome GnuPG

Make it possible to restore MIME crypto mails to original
Closed, ResolvedPublic

Description

GpgOL modifies MIME messages as outlined in https://wiki.gnupg.org/GpgOL/MIMESupport

This modification should be reversible so that other clients and, for S/MIME,
Outlook itself can handle the messages again properly.

I would classify this as a new feature because it was always a problem even
before 1.3.0 for Outlook < 2010

Details

Version
1.3.0

Event Timeline

I'm optimistic this can be done. :-)

It's a bit iffy though and might be especially annoying from a performance side
for exchange users. Still it will be better then the Status Quo because you can
still use the mails with other clients.

The trick is not to revert back the message in the Write event, as we have to
work on the OOM in the Write event but in the AfterWrite event where we can work
on MAPI.

I could modify / restore the mail there already using old code. The message is
not formed correctly but this looks like just a bug in the revert code.

Modifying the mail in the afterwrite event did not work good. While the
attachment changes were synced to the server Outlook itself didn't reparse the
mail correctly. This let to a weird out of sync situation between MAPI and OOM.
But testing looks like this could work from the Write event indeed. Which would
be even better because we only have one write and we could replace the "Wipe
Message" code completely by just reverting the mail back to the original.

More difficult then I thought.

For PGP/Inline this should currently work. I had the problem that I can't
manipulate the Body in MAPI but over Outlook in the write event this worked.

PGP/Clearsigned support i've disabled for now.

With regards to mime mails:

I could modify / restore the mail there already using old code. The message
is not formed correctly but this looks like just a bug in the revert code.

As it turns out this was totally an understatement ;-) The old revert code can't
have worked. Maybe for S/MIME under some circumstances but otherwise not.

The problem is the main part how Outlook builds the MIME message. Were we have
very limited control about it. Just removing our attachments and leaving the
original MIME attachment leads to a MIME structure like:

<quote>

This is a multipart message in MIME format.

------=_NextPart_000_0000_01D12C53.76E82C90
Content-Type: multipart/alternative;
boundary="----=_NextPart_001_0001_01D12C53.76E82C90"

------=_NextPart_001_0001_01D12C53.76E82C90
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

------=_NextPart_001_0001_01D12C53.76E82C90
Content-Type: text/html;
protocol="application/pgp-encrypted";
boundary="nextPart3167407.zD7nylcVYN";
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-W3CDTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
rmj.rmm.rup.rpr">
<TITLE></TITLE>
</HEAD>
<BODY>
<!-- Converted from text/rtf format -->
<BR>

</BODY>
</HTML>
------=_NextPart_001_0001_01D12C53.76E82C90--

------=_NextPart_000_0000_01D12C53.76E82C90
Content-Type: application/pgp-encrypted;
name="Unbenannte Anlage 00001.dat"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename="Unbenannte Anlage 00001.dat"

Version: 1
------=_NextPart_000_0000_01D12C53.76E82C90
Content-Type: application/octet-stream;
name="msg.asc"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename="msg.asc"

-----BEGIN PGP MESSAGE-----
Version: GnuPG v2

hQEMAx7U8Lxs+8kSAQf/eB4zBTz/VSVBBI+ihh/PSorJ98BRh5earBqF8HjmGZce

<end quote>

This is nothing even an MUA like KMail can handle. And GpgOL can handle this
neither. So if we modify the message we have to do it somehow in a way that
Outlook builds a Mime structure again that users can work with.

As we can actually send MIME messages I looked at the code in mimemaker that
builds a message. Using some tricks from there I was able to recreate a PGP/MIME
mail. But this needs special handling for all our message classes.

Still too buggy to commit. Leaks plaintext and I have at least seen that it led
to a duplicated message once.

gpgol 2.0 won't change the messages on the server anymore there might be code
paths leading to that under error conditions but i'm not aware of any. And the
fallback is first to try to revert them.