Signature Handling in Emails

There are three different ways of handling signatures in emails:

1. MIME (prefered way)

PGP/MIME or S/MIME standards.

• Example:

      Content-Type: multipart/signed

      Content-Type: text/plain
      This is the text.

      Content-Type: application/pgp-signature; name=signature.asc 
      -----BEGIN PGP SIGNATURE-----
      iQEXYZXYZ
      -----END PGP SIGNATURE-----

• Advantages:
  • attachments are signed as well
  • no encoding problem
  • easy way to encrypt a signed structure
  • all MIME compatible clients show the signed text, even if they cannot understand the signature

• Disadvantages: Some email applications are not MIME compatible, e.g. Outlook in some versions requires the user to explicitely open the body as attachment.

• Conclusion: This is best for the user experience and compatibility. In short: You really want proper MIME handling like with PGP/MIME!

2. "no-mime" (old term: "clearsign")

Some people used to call this "clearsigned", but we believe this to be missleading. "clear" is something positive, something you would want. But we know that the user experience is much better with the PGP/MIME way of clearsigning the mail body. The chance to see the text correctly with PGP/MIME is much higher and the email is better structured, aka more clearly structured. Therefore '''we suggest to give the old format a different name: "no-mime signed"'''.

We will certainly use "no-mime" signature as a description of this less wanted method to sign a mail body contents everywhere. No-mime maybe a slightly better solution that just using attachments for email communication, but at least its name is more intuitive.

• Example:

      ----BEGIN PGP SIGNED MESSAGE-----
      This is the text.
      -----BEGIN PGP SIGNATURE-----
      iQEXYZXYZ
      -----END PGP SIGNATURE-----

3. "double no-mime"

This is a new format to try out in GpgOL 1.2.0 for Outlook 2010 and 2013. The body text is included twice, so we call it "double no-mime". You can see its structure in the example.

• Example:

      This is the Text
      -----BEGIN PGP MESSAGE-----
      XYZXYZ                        <- contains "This is the Text" again, **unencrypted**
      -----END PGP MESSAGE-----

• Advantage:
  • works with PGP and CMS (less enconding problems).

• Possible disadvantage:
  • Other clients do not display the contained text, but the surrounding text instead.

We will seek feedback on this and will evaluate if this new format is an improvement or not. And we may remove it again in GpgOL.