On Tue, 09 Nov 2004 12:09:08 EST, Bill Verity said:
> Some clients are starting to use S/Mime to add signatures to their
> email that securely sign their mail.  This seems to work fine on
> lists that don't add material to the note body, but of course top and
> bottom banners will break these signatures since the body of the note
> changes.  Some people have asked if the banners could be omitted if
> the original note had an attachment identified as
>
> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature";

What about "multipart/signed; protocol="application/pgp-signature"? :)
(Not fair, at least PGP doesn't complain if there's trailing trash appended
to the multipart/signed - I'm surprised that x-pkcs7 barfs on this case.)

The *right* way to fix this, if such a fix is actually needed, of course, is
that if the mail is a multipart/*, to rebuild it as:

multipart/mixed
  text/plain (the top banner, if any)
  multipart/* (the original message)
  text/plain (the bottom banner, if any)

Mailman 2.1.5 seems to implement this, at least for bottom banners.

Incidentally, any software that complains about trailing trash breaking
a digital signature needs to read RFC2046, section 5.1:

   In the case of multipart entities, in which one or more different
   sets of data are combined in a single body, a "multipart" media type
   field must appear in the entity's header.  The body must then contain
   one or more body parts, each preceded by a boundary delimiter line,
   and the last one followed by a closing boundary delimiter line.

So if there's no trailing boundary delimiter, the text isn't a body part, but
an "epilogue" area, and as a result should not be included as a "Leaf Part" in
Step 2 of RFC2633, section 3.1. As such, it shouldn't break the signature.

Similarly, top banners should end up being "silently swallowed", as they
fall into the "preamble" area.  RFC2046, section 5.1, says:

   NOTE:  These "preamble" and "epilogue" areas are generally not used
   because of the lack of proper typing of these parts and the lack of
   clear semantics for handling these areas at gateways, particularly
   X.400 gateways.  However, rather than leaving the preamble area
   blank, many MIME implementations have found this to be a convenient
   place to insert an explanatory note for recipients who read the
   message with pre-MIME software, since such notes will be ignored by
   MIME-compliant software.


I have to say that making a change to Listserv to work around non-RFC-compliant brain-damage
in other software is a Bad Idea...