One of the more difficult issues for OpenPGP-aware E-Mail clients
is the support and treatment of different e-mail formats, i.e.
PGP/INLINE, PGP/MIME, and the variants thereof. While developers
are usually aware of the quirks of their own implementations,
it is difficult to find reliable documentation on the matter
without doing extensive research on the clients.

I would like to collect on this page the behavior of different
implementations, for both sending and receiving e-mail. It is more
important to have a general overview here than a deep understanding
of each implementation, so information should be kept to the point.
I will make a start, feel free to use the same fields or suggest a
better way to structure this information when you add your own.

Format overview (did I forget anything?):
* PGP/MIME ([[https://tools.ietf.org/html/rfc3156#page-7|RFC1847]])
* PGP/MIME ([[https://tools.ietf.org/html/rfc3156#page-8|Combined]])
* PGP/INLINE as PGP MESSAGE
* PGP/INLINE clearsigned
* PGP/PARTITIONED ([[http://www.ietf.org/mail-archive/web/openpgp/current/msg01811.html|partitioned]]) 
* PGP/PEP (definition will follow soon in [[https://cacert.pep.foundation|p≡p development wiki]])

* Memoryhole (be the first!)

== K-9 Mail + OpenKeychain

Supported receiving formats: PGP/INLINE, encrypted and clearsigned \\
Preferred receiving format: PGP/INLINE

Supported sending formats: PGP/INLINE \\
Preferred sending format: PGP/INLINE

=== Platform limitations and quirks:
The current stable release is based on the original Android
Open Source Project E-Mail client, which squashed all mail at
receive time into a single html blob to display for performance
reasons, irrecoverably losing necessary information for PGP/MIME
processing.

=== Planned development:
Full PGP/MIME support is in the works. The development master
has a revised database architecture but is missing a migration
mechanism. PGP supported is patched directly into the K-9 code,
so there are no technical limitations.

Contact for questions: Vincent Breitmoser <look@my.amazin.horse>

User-Agent Header: "K-9 Mail for Android"

== GpgOL

There ist currently ongoing development in GpgOL for Outlook 2010
and later and a build option to enable sending PGP/MIME there too.

=== Outlook < 2010
Supported receiving formats: PGP/MIME, PGP/INLINE \\
Preferred receiving format: PGP/MIME

Supported sending formats: PGP/MIME \\
Preferred sending format: PGP/MIME

=== Outlook >= 2010 (Version 1.3)

Supported receiving formats: PGP/MIME, PGP/INLINE, encrypted, clearsigned and opaque \\
Preferred receiving format: PGP/INLINE, When only signed, please **NOT clearsigned** but as opaque PGP MESSAGE.

Supported sending formats: PGP/INLINE not clearsigned but opaque \\
Preferred sending format: PGP/INLINE

Attachment handling: pgp/partitioned style (without using this content type) with attachments as single PGP Message

=== Platform limitations and quirks:
The current (1.3.0) versions for < 2010 and >= 2010 modify a Mail in place making them incompatible with other readers.
(See: [[GpgOL/MIMESupport]])

==== Attachment filenames

Attachment file names are always a bit of a problem with outlook as it uses RFC2047 encoding and
not RFC 2231

Sending:

GpgOL tries to send filenames encoded like outlook does. This is currently RFC2047. Quoted Printable if less then 20%
of the characters need to be encoded otherwise base64. Charset is always UTF-8.

Recieving:
GpgOL reads encoding like outlook does. It prefers the "Content-Type name" value.

Ideally you should send someting like thunderbird / enigmail does e.g for "Däß üst äin Töst.txt":

{{{
Content-Type: text/plain; charset=UTF-8;
 name="=?UTF-8?B?RMOkw58gw7xzdCDDpGluIFTDtnN0LnR4dA==?="
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename*0*=utf-8''%44%C3%A4%C3%9F%20%C3%BC%73%74%20%C3%A4%69%6E%20%54%C3;
 filename*1*=%B6%73%74%2E%74%78%74
}}}


=== Planned development:
The development version saves the mails in a way that they can still valid.
This fails for multipart/signed mails as Outlook modifies the
inner boundaries of the mime mail to have a linebreak/tab
after each semicolon. So only mails where the inner boundaries already
looked that way are correctly restored after viewing.

We are evaluation ways to get rid of the modification altogether as this
leads to several problems.

Sending MIME Messages is also supported in the development version.

No user agent header. But sends:

X-Mailer:	Microsoft Outlook <version>

Contact for questions: Andre Heinecke <aheinecke@intevation.de>

== KMail
Supported receiving formats: PGP/MIME, PGP/INLINE \\
Preferred receiving format: PGP/MIME

Supported sending formats: PGP/MIME, PGP/INLINE (clearsigned) \\
Preferred sending format: PGP/MIME

Can send GpgOL compatibile attachment names in PGP/MIME mails when the option "Outlook compatibile attachment names" is configured.

User-Agent Header: KMail/<version>

Contact for questions: Andre Heinecke <aheinecke@intevation.de>

== p≡p

Supported receiving formats (OpenPGP compatible only): PGP/MIME, PGP/PARTITIONED, PGP/PEP \\
Supported sending formats (OpenPGP compatible only): PGP/MIME, PGP/PARTITIONED, PGP/PEP

Preferred sending format for OpenPGP communication partners: PGP/MIME \\
Preferred sending format for p≡p communication partners: PGP/PEP

x-pep-version: 1.0

Contact for questions: p≡p communication team <pep@pep-project.org>

Memoryhole will be fully supported in case of support of other major contributors