GnuPG Gpg4win Logo
  • Comments
  • Immutable Page
  • Menu
    • Navigation
    • RecentChanges
    • FindPage
    • Local Site Map
    • Help
    • HelpContents
    • HelpOnMoinWikiSyntax
    • Display
    • Attachments
    • Info
    • Raw Text
    • Print View
    • Edit
    • Load
    • Save
  • Login

Navigation

  • RecentChanges
  • FindPage
  • HelpContents

Upload page content

You can upload content for the page named below. If you change the page name, you can also upload content for another page. If the page name is empty, we derive the page name from the file name.

File to load page content from
Page name
Comment
Get the password from https://wiki.gnupg.org/UnlockRegistration

  • GpgOL
  • MessageConversion

Contents

  1. Background: Message conversion in GpgOL
    1. OpenPGP Encrypted
    2. OpenPGP Signed
    3. S/MIME Encrypted with Exchange 2016 and later
    4. S/MIME Encrypted with Exchange 2013 and 2010
    5. SMIME Signed
  2. Interoperability issues

Background: Message conversion in GpgOL

Microsoft uses both in Exchange and in Outlook the MAPI 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 OutlookSpy

When a message is sent over the internet through SMTP Outlook or Exchange (depending on weather the client is connected to an Exchange over the MAPI protocol or not) convert the message from MAPI to the RFC-822 MIME 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 MSDN: Content conversion

More details about the conversion are documented as MS-OXCMAIL

GpgOL utilizes the special handling offered for S/MIME for both S/MIME and OpenPGP. This is documented as: 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. 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

  • This site is hosted by Intevation GmbH
  • |
  • Datenschutzerklärung und Impressum
  • |
  • Privacy Policy and Imprint