It seems like inline PGP messages just can't be eradicated, despite
all the PGP/MIME we have. I'm wondering if it would be reasonable
to produce an RFC on (1) how to tag this on the MIME level, and (2)
how to avoid character set problems.
Here's the simple proposal (in rough words), as currently
implemented in the Mutt mail user agent.
1. Inline PGP messages use text/plain as their MIME type. Inline
PGP material is announced in an additional MIME parameter (we call
it x-action right now), which can take the values "pgp-encrypt",
"pgp-sign".
2. Clearsigned messages are converted to UTF-8 before they are
signed and sent. Since UTF-8 is OpenPGP's standard text character
set, there is no Charset armor header. The MIME charset header is
set to utf-8 as well.
3. Encrypted messages are likewise converted to UTF-8 before they
are passed to OpenPGP. Once again, there is no Charset header on
the ASCII armor. However, on the MIME level, the message will be
us-ascii -- we're using ASCII armor.
What's gained by this? You don't have to look at the contents of
body parts in order to identify PGP material, which saves you a lot
of time. You don't have the complications with non-compliant mail
user agents which are caused by content types like application/pgp.
You avoid character set conversion confusions.
If there is any interest in documenting this as an RFC, I'd be
willing to do the drafting.
Regards,
--
Thomas Roessler <roessler(_at_)does-not-exist(_dot_)org>