= Background: Message conversion in GpgOL =

Microsoft uses both in Exchange and in Outlook the ~M~A~P~I data format. This is a specific format that saves things like the body or the subject as object properties.


{{ol-mapi.png}}

When a message is sent over the internet through ~S~M~T~P Outlook or Exchange (depending on weather the client is connected to an Exchange over the ~M~A~P~I protocol or not) convert the message from ~M~A~P~I to the ~R~F~C-822 ~M~I~M~E Format. As this modifies the mail it would break the structure of a PGP/MIME or S/MIME message.
When the conversion occurs is documented in ~M~S~D~N: [[https://docs.microsoft.com/en-us/exchange/mail-flow/content-conversion/content-conversion?view=exchserver-2019|Content conversion]]


More details about the conversion are documented as [[https://docs.microsoft.com/en-us/openspecs/exchange_server_protocols/ms-oxcmail/54a49716-5cb2-41e3-8ae8-874eca8b026f|MS-OXCMAIL]]


GpgOL utilizes the special handling offered for S/MIME for both S/MIME and ~Open~P~G~P. This is
documented as: [[https://docs.microsoft.com/en-us/openspecs/exchange_server_protocols/ms-oxosmime/e8a99aaf-6b1b-45e5-8b7d-4440ed01073b|MS-OXOSMIME]].


Following is a description of what this concretely means:

== OpenPGP Encrypted ==

Message class: {{{IPM.Note.InfoPathForm.GpgOL.SMIME.MultipartSigned}}}
Empty body (no or empty {{{PR_BODY}}} property)
One attachment which contains the MIME structure with the header:

{{{
MIME-Version: 1.0
Content-Type: multipart/encrypted;
protocol="application/pgp-encrypted";
boundary="someboundary"
}}}

== OpenPGP Signed ==

Message class: {{{IPM.Note.InfoPathForm.GpgOLS.SMIME.MultipartSigned}}}
Empty body (no or empty {{{PR_BODY}}} property)
One attachment which contains the MIME structure with the header:

{{{
MIME-Version: 1.0
Content-Type: multipart/signed;
protocol="application/pgp-signature";
micalg=SHA-256;
boundary="someboundary"
}}}

== S/MIME Encrypted with Exchange 2016 and later ==

Message class: {{{IPM.Note.InfoPathForm.GpgOL.SMIME.MultipartSigned}}}
Empty body (no or empty {{{PR_BODY}}} property)
One attachment which contains only the S/MIME encrypted data. No header.

Additionally we set {{{PR_PIDNameContentType_DASL}}} to: {{{"application/pkcs7-mime;smime-type=\"enveloped-data\";name=smime.p7m"}}}
to inject the proper header.

== S/MIME Encrypted with Exchange 2013 and 2010 ==

Message class: {{{IPM.Note.InfoPathForm.GpgOL.SMIME.MultipartSigned}}}
Empty body (no or empty {{{PR_BODY}}} property)
One attachment which contains the MIME structure with the header:

{{{
MIME-Version: 1.0
Content-Type: application/pkcs7-mime;
smime-type=enveloped-data;
name="smime.p7m"
Content-Disposition: attachment; filename="smime.p7m"
Content-Transfer-Encoding: base64
}}}

== SMIME Signed ==
GpgOL only sends Multipart signed messages, never Opaque signed.

Message class: {{{IPM.Note.InfoPathForm.GpgOLS.SMIME.MultipartSigned}}}
One attachment with the Header:

{{{
MIME-Version: 1.0
Content-Type: multipart/signed;
protocol="application/pkcs7-signature";
micalg=SHA-256;
boundary="someboundary"
}}}


= Interoperability issues =

It has been noted that some clients do not handle our Mails well when
the MAPI to MIME conversion does not happen. E.g. If mails are exchanged
on the same Exchange Server with different client.

This happens for S/MIME Mails because most clients do not recognize
the InfoPathForm type of the message class. For future versions
it might be helpful to change S/MIME message classes
to IPM.Note.SMIME and IPM.Note.SMIME.Multipart signed as the
InfoPathForm is mostly used to present a different icon for
the Mails.