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...