When an S/MIME Signed mail contains PGP/Inline data it is not handled by GpgOL. GpgOL sees that it is S/MIME and either treats it as an S/MIME mail or if S/MIME is disabled just does nothing with the mail.
Some solutions might send that with gateway solutions that sign everything so it would be nice if GpgOL would handle this.
| rO GpgOL | |||
| rO0e05606f6931 Also check for pgp/inline in IPM.Note.SMIME | |||
| rO1656e01d2eb1 Check for PGP/Inline inside of S/MIME mails | |||
It's not super good but now when S/MIME is disabled we also look into the body of S/MIME mails to check for the PGP Inline message marker.
This will only work for new mails which were never looked at in GpgOL as old mails are marked as S/MIME mails already and to avoid regression risks with this corner case old message classes are not changed.
I have to revert the changes. The problem is that with attachments included Outlook must parse the S/MIME Mail. The code I've added to handle the PGP/Inline in GpgOL would result in hidden attachments as Outlook no longer properly parses the S/MIME Mail, we only decrypt the body and so attachments are gone.
This is a bigger issue :-/
Note to self. For Backwards compatibility :
diff --git a/src/mapihelp.cpp b/src/mapihelp.cpp index d9e276d..c8c0561 100644 --- a/src/mapihelp.cpp +++ b/src/mapihelp.cpp @@ -3419,6 +3419,17 @@ mapi_mark_or_create_moss_attach (LPMESSAGE message, msgtype_t msgtype) table[i].attach_type == ATTACHTYPE_MOSS || table[i].attach_type == ATTACHTYPE_MOSSTEMPL) { + if ((msgtype == MSGTYPE_GPGOL_PGP_MESSAGE || + msgtype == MSGTYPE_GPGOL_CLEAR_SIGNED) && + table[i].attach_type == ATTACHTYPE_MOSS) + { + /* This can happen if a PGP/Inline message was classified + wrongly in the past. */ + log_error ("%s:%s: Found MOSS attachment for inline msg. " + "Ignoring it.", + SRCNAME, __func__); + continue; + } if (!part1) { part1 = i + 1;
I think this can go to wontfix for now. Inline PGP inside of S/MIME,.. well that is not good.