[PATCH]: Optional explanation for options

[Lars Wirzenius]

ma, 2005-09-19 kello 19:12 +1000, Robert Collins kirjoitti:
> On Mon, 2005-09-19 at 09:59 +0100, Magnus Therning wrote:
> ..
> > That'd mean they mess up digital signatures as well, right?
> 
> RFC???? signatures are done by having an empty body, two MIME
> attachments, one of which is the signature and the other the content.
> 
> An interesting bug in some list handlers is when they insert 'list
> foo-bar' trailers to messages, they result in an email with that message
> as the body, which RFC???? mailers don't display at all :).
> 
> BTW: can't remember the number offhand - sorry. There are two rfcs, one
> for the generic approach, one for pgp specifically.

I think you mean RFC2015 (http://www.ietf.org/rfc/rfc2015.txt). More
links at http://www.imc.org/smime-pgpmime.html if you want.

It's not actually an empty body, unless I misremember badly. It's like
this:

        From: whoever
        To: whomever
        Subject: whatever
        Content-type: multipart/signed; boundary=xxx
        
        --xxx
        Content-type: text/plain
        
        The message to be signed.
        --xxx
        Content-type: application/pgp-signature
        
        ------BEGIN PGP MESSAGE------
        THEDETACHEDSIGNATURECOMESHERE
        ------END PGP MESSAGE------
        --xxx--
        
MIME multipart messages don't have a "body" and "attachments", although
that is how they are usually used (with Content-disposition indication
the role of each part). For a multipart/signed type message
specifically, there are two parts: the actual message and a digital
signature. The actual message is of type text/plain above, but can be
anything, including a multipart. The point is to make it possible to
automatically check the signature for a message and then have the user
interface only show the actual message, since the signature is
irrelevant to the user, if it checks out.

The parts of a multipart message before the first delimiter (first
"--bar" above) and after the last ("--bar--" above) are explicitly
off-limits to a MIME aware mail user agent, meaning that they do not
contain text that is relevant to the actual message content. Typically
the part before the first delimiter contains a short explanation that it
is is a MIME message and that the user needs a MIME aware mailer to read
the message properly. This is what allows mailing lists to add a footer
after the last delimiter (and many do), without breaking anything, or at
least things will break quite rarely, if care is taken (e.g., the footer
must use a suitable charset; in practice, us-ascii). Of course, a MIME
aware mailer won't show the footer if the message is multipart; at least
for my list manager, this is considered a feature, not a bug.

That was a load of off-topic blather, sorry. To bring this back on topic
for bzr, I'll say something about MTAs, MUAs, and other mail processing
software and whether they mangle messages.

They do, we have to live with it. There is practically no part of any
Internet e-mail specification that isn't being violated daily, somewhere
on the network.

MIME specifications contain a fair amount of stuff that has been added
there just to avoid breakages because of, say, whitespace being deleted
from the ends of lines (use quoted-printable, encode trailing whitespace
with =20). Unfortunately these seem to still be necessary, because so
much mail goes through big commercial organiztions that often run Lotus
Notes, or other proprietary mail systems that don't do native Internet
mail, or others that are just broken.

It makes sense to keep or the patch format insensitive to the commonest
manglings: trailing whitespace is eaten, line terminators are converted,
tabs might get expanded, a ">" is added before a "From" at the beginning
of a line, and so on. At least to make possible to detect that something
has been mangled; an embedded checksum (of a normalized version that
disregards line terminator changes), for example, could easily be used,
and won't disturb the patch utility, which happily ignores things
outside the parts it's supposed to apply (an ingenious design decision).

Choice of MIME Content-type and encoding also matter, of course,
although I guess bzr can't affect that much itself. Unencoded text/plain
is more commonly mangled than application/octet-stream with base64
encoding, but the latter would be unacceptably hard to use for other
reasons.