This page covers the different types of signing, how they work, and their pros and cons. Finally, I've built a support matrix of various MUAs and how they respond to each.
The way to sign a text file using PGP is called clear-signing. It works by putting the signature in-line with the text you are signing. For example:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
this is some test text
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
iD8DBQFDDA1eN5XoxaHnMrsRAsOPAKCBrt/YQuI8/rSD3rfQpYxJZowFPACdEYS5
VoXLQNhyvirGLwvIZjuJLHY=
=xGk+
-----END PGP SIGNATURE-----
GPG can then verify this:
[phil@rider tmp]$ gpg --verify foo.asc
gpg: Signature made Thu Aug 25 22:49:27 2005 PDT using DSA key ID A1E732BB
gpg: Good signature from "Phil Dibowitz <phil@ipom.com>"
gpg: aka "Phil Dibowitz <webmaster@ipom.com>"
Therefore it was easy to make mail clients pipe text through pgp to either sign or verify email. Thus the first PGP-based email signing was born!
Version 1.4 of mutt, and perhaps other clients, attempted to use this ill-conceived "application/pgp" MIME type when signing traditional messages and then specifying "content-disposition: inline." However, most mailers won't display anything inline unless it's content-type is plain-text. (which by all means is what the body of a message should be when it's in text). This was never picked up as a standard or my most mailers (except mutt 1.4; but mutt abandoned this in 1.5). If you would like to use traditional signing, I suggest you ensure your client is doing it properly, and not using application/pgp. Since application/pgp is very rare, this shouldn't be a problem.
So traditional signing was ugly - clients that didn't support PGP showed all this ugly extra text, and many clients that did support PGP still showed this text. So a new solution was proposed. Originally, RFC 2015: MIME Security with Pretty Good Privacy (PGP) purposed some new MIME types and allowed for separation of the signed data and the signature. RFC 3156: MIME Security with OpenPGP further revises this process.
The gist is that message will be of type "multipart/signed" and the actual body will be "Content-type: text/plain" (or, if you're truly evil, text/html), which tells the client this is a part that should be displayed (while it's not specified, "content-type: plain/text" generally implies "content-disposition: inline"). Then the next part has "Content-type: application/pgp-signature", which clearly is not of type text, and should not be displayed. In this way, clients that don't support PGP see a clean message. They will have a small attachment they can ignore, but the message is no longer confusing. MIME is a complicated subject, but RFC 2046: Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types will give you all the gory detail if you'd like.
This cleans everything up nicely - if you don't support PGP, you see a nice clean message, and if you do, you can sign/verify at will. All that is required is a mail client that supports the basic principals of MIME, and since RFC2045 and RFC2046 (which define MIME) were published in November 1996, almost any modern mail client qualifies, including many command-line clients.
Unfortunately, a few clients, namely Microsoft's Outlook Express, still don't follow MIME properly and thus don't display the body of the message inline and users just get a blank email and two attachments and therefore need to open an attachment to see the email.
This matrix shows how various MUAs handle the various kinds of signing. MUAs that have PGP plugins are listed separately with and without the plugin.
| Client | Traditional | PGP/MIME |
|---|---|---|
| Outlook (2k & 2k3) | Displays message (with headers) | Displays message |
| Outlook Express | Displays message (with headers) | Does not display message Can't even double-click to view - must download and open separately |
| Thunderbird | Displays message (with headers) | Displays message |
| Thunderbird + Enigmail | Displays & verifies message | Displays & verifies message |
| Pine | Displays message (with headers) | Displays message |
| Pine + Pine Privacy Guard | Displays & verifies message (with headers) | Displays message |
| Mutt | Displays & verifies message | Displays & verifies message |
| Apple Mail | Displays message (with headers) | Displays message |
| Apple Mail + GPG Mail | Displays & verifies message | Displays & verifies message |
| Eudora | unknown | unknown |
So while traditional signing will allow the widest range of non-PGP-ized users to read the contents of your message without any extra clicks, it will also display a lot of extra headers (see the top of this page) which may confuse them.
Conversely, as long as your correspondents don't use Outlook Express (which is EOL'd anyway), the almost everyone you write to, regardless of if they have PGP support, will see your message clearly and merely have an extra attachment they can ignore.