--2JFBq9zoW8cOFH7v
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, Aug 02, 2002 at 07:39:34PM -0400, Todd Vierling wrote:
> On Fri, 2 Aug 2002, Ignatios Souvatzis wrote:
>=20
> : > We'll use this to see how many people check sigs ;-)
> :
> : I'd auto-check them if they had proper PGP/MIME headers...
>=20
> Please don't use "application/pgp".  This **DOES NOT** come up as plainte=
xt
> in the majority of MIME-aware MUA's, and thus, it should only be used for
> ASCII armored (or base64-encoded binary) PGP blocks.

Or course not. E.g. Mutt creates this:

> Mime-Version: 1.0
> Content-Type: multipart/signed; micalg=3Dpgp-md5;=20
>         protocol=3D"application/pgp-signature"; boundary=3D"5vNYLRcllDrim=
b99"
> Content-Disposition: inline

where the first part is text/plain, if it was text/plain before, or whatever
your message was before signing. It seems to properly encapsulate and sign
multiparts etc. if necessary, I've used this before.

I believe there is an RFC standardizing this, analog to the PEM one, but it
has been a few years since I studied them.

I can see why SO announcements might NOT use this -=20
SO want to have the same message they send out available on the ftp server,
while creating PGP/MIME involves creating a detached signature.

OTOH, storing a seperate signature per announcement might be ok.

Regards,
	-is

--2JFBq9zoW8cOFH7v
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (NetBSD)
Comment: For info see http://www.gnupg.org

iD8DBQE9UClLPCRcZ/VMtk4RAn/mAJ98/q23PLsAftnefC6J+Q0Y30l7CwCeJRG+
LElLZRRCeyDFlfTreaQy4js=
=65Tb
-----END PGP SIGNATURE-----

--2JFBq9zoW8cOFH7v--