<<TableOfContents(3)>>

= 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}}\\
//A view of MAPI Properties in outlook with the tool Outlook~Spy//

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 ~M~A~P~I to M~I~M~E 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 ~Info~Path~Form type of the message class. Since GpgOL 2.3.x the message class is changed
back to the original S/MIME message classes {{{IPM.Note.SMIME and IPM.Note.SMIME.Multipart}}} after
the mail is handled by GpgOL. If you find interoperability issues please report them under https://dev.gnupg.org