Michael Thomas writes: > Let's be clear that I'm advocating a dialog here,
In some sense, there's very little room for dialog, unless it involves substantial amendments to DKIM. This is inherent in the design: the whole message is signed. Preserve it nearly verbatim or break the signature. This need not be a problem, however, as long as users can be taught not to panic because one signature doesn't verify. See below. > I'm hoping that we can come up with some finesse. It's not obvious to me that a finesse is necessary or desirable. IMO, the right answer is for mailing lists to sign the posts that pass through them, and to publish a BCP that extols the manifold advantages to lazy admins<wink> of vetting a bunch of mailing lists and then trusting the signatures of the trustworthy ones. The transition period may be painful, but so is spam. > In any case, if you have some ideas about what list friendly > wording is, I'd be happy to hear it. After reading dkim-base-8, things are a lot clearer. Specifically, the updated Section 4 makes it clear that there's no reason why a mailing list is a second-class citizen: Of course, a message might also have multiple signatures because it passed through multiple signers. A common case is expected to be that of a signed message that passes through a mailing list that also signs all messages. Assuming both of those signatures verify, a recipient might choose to accept the message if either of those signatures were known to come from trusted sources. While I could wish for a stronger endorsement, I realize that is about as strong an endorsement as you'll find in an informative section in a standards-track RFC. I guess in the BCP I'd like to see that language (at least) repeated with encouragement to implementers to (eg) have verifiers look for a mailing list signature if RFC 2369 headers are present. The heuristic being the one I've been hammering on: if your users are subscribed to a mailing list, they evidently trust it to a greater or lesser degree. And of course users and ISPs should be encouraged to use MUAs and servers that employ verifiers with those features. By the way: *WARNING* Most of the links from the DKIM site point to version dkim-base-7b, while the current version is dkim-base-8. The latter has a much more satisfactory Section 4 (on multiple signatures). Most recent version (currently v8) is here: https://datatracker.ietf.org/public/idindex.cgi?command=id_detail&id=14210 _______________________________________________ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp
