[extropy-chat] Eugen's signed messages

[Hal Finney]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Damien commented:
> I am still getting all of Eugen's posts (such as this one) as attachments,
> not in the email message body. I dislike opening attachments, even from
> someone trustworthy (or someone pretending to be someone trustworthy, which
> is the problem).

Eugen is signing his messages using gpg, the popular open source
implementation of the OpenPGP standard for using public key cryptography.
The messages are MIME formatted per RFC 3156.  This creates a message
with two parts; the first part contains the message body, and the second
part contains the cryptographic signature.

MIME mail has several variants on multipart messages.  For cryptographic
signatures, multipart/signed is used.  So Eugen creates a multipart/signed
message that has two body parts.

However, the extropy-chat mailing list processor is then further processing
this message.  It wants to append the trailing lines, which we have all
seen:

: _______________________________________________
: extropy-chat mailing list
: extropy-chat at lists.extropy.org
: http://lists.extropy.org/mailman/listinfo/extropy-chat

Normally it just sticks these lines onto the end of the message, but for
a MIME multipart message, this won't work.  You can't just append data
after the end of the multiparts, as that puts it outside the structure
and so it either will be ignored or might even cause some kind of error.

Nor can the extropy-chat mailer extend Eugen's multipart message with a
third part to hold the trailing lines, because multipart/signed messages
have specific rules that they should have exactly two parts.

So what the list does is to further wrap Eugen's multipart message in a
higher level multipart, this one of type multipart/mixed.  This type of
multipart is a sort of catchall or generic multipart, where the multiple
parts are intended to be displayed one after the other.

The multipart/mixed messages created by the list has two parts.  In the
first part, it puts Eugen's multipart/signed message (which itself has
two parts).  In the second part, it puts the three trailer lines above.
This is the message which the list sends out.  It has the following
structure:

multipart/mixed
    multipart/signed
        Eugen's message
        Eugen's signature
    extropy-chat list trailer

A compliant mailer will see through this complexity and display
the various parts directly.  Each of the parts has the tag:
"Content-Disposition: inline" which is a hint that the contents should
be displayed directly.  If it said "Content-Disposition: attachment"
then it should be displayed as an attachment (typically the contents
are saved as a file and the message displays a link to the file).

Ideally the mailer will even be smart enough to try to validate the
cryptographic signature.  But failing that, unrecognized multiparts are
specified to be treated as multipart/mixed, meaning that the parts should
just be displayed, one after the other.  And since each is marked for
"inline" display, that should further assure the mailer that the right
thing to do is to display the various messages parts, all concatenated
together.  The signature might present a problem, as it is of type
"application/pgp-signature" which a mailer might not recognize, so that
might be skipped or presented as an attachment.

However, many mailers are not this smart.  And the complex nature of the
message sent out by the list, with its two-level hierarchical structure,
probably doesn't help.  I don't know whether there exist mailers that
could handle a regular multipart/signed message while choking on one
that is embedded within multipart/mixed, but there might be some for
which this makes a difference.

The real lesson is that protocol implementations tend not to work properly
with data structures that they have not been tested on.  That's why
implementors have "bake-offs", get-togethers where they test each other's
programs and see if they can interoperate.  Surprisingly, even when
a well written spec is implemented by competent programmers, usually
things don't work on the first try (any more than any large program is
born free of bugs).  It's not a moral failing; it's just a manifestation
of the difficulty the human mind has in processing abstract information.

Hal

-----BEGIN PGP SIGNATURE-----
Version: McAfee E-Business Server v7.1.2 - Full License

iQA/AwUBP6FrMKsSfKQ41E4qEQJ/yQCfUAWmCzz738LXtcK8ft/3lJRjKi0AoPi1
sWYBv0IYtR/UqqSJ6t1WCQdn
=+vxQ
-----END PGP SIGNATURE-----