Grant Taylor writes: > On 1/19/2009 10:19 PM, Taylor, Grant wrote: > > I will play with forwarding an S/MIME signed / encrypted message and > > let you know what my MUAs (of choice) do with the message/rfc822 MIME > > body part.
This isn't really relevant to Mailman, though. MIME messages are by design recursively structured, and MUAs that claim to support S/MIME should be able to handle recursive structure. The only responsibility Mailman has or should accept is to encapsulate signed bodies verbatim so as not to break the signature. > This means that it is possible to enclose a multipart/signed message as > a message/rfc822 MIME part and have it successfully display. The only > problem is that the attachments them selves would have to be opened (as > opposed to viewing them inline) to have any indication if the signature > is valid. The user should put in an RFE for your MUA if that extra effort bothers him. If he hasn't validated the signature himself, he has to assume that it is invalid. This is not a task that can be delegated to mailing list software. > Thus I think that Mailman (or any thing else doing similar > types of operations) should attach the original signed message as a > message/rfc822 MIME part *AND* sign it's own message including a textual > note that the original message had a valid signature. Please, no. That's an open invitation to phishing. To prevent it robustly, Mailman would have to remove signatures that it can't validate, otherwise a message could be crafted to look like one that was validated by Mailman. But that is clearly the wrong thing to do, as the recipient might be able to validate signatures that Mailman cannot. ------------------------------------------------------ Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9