--On 12 October 2009 10:04:17 -0400 Wietse Venema <[email protected]> wrote:
> Michael Deutschmann: >> If this is indeed the official semantics of the protocol, then I would >> petition to add a "dkim=except-mlist" policy. Which means "I sign >> everything that leaves my bailiwick, but may post to signature-breaking >> MLs." > > Are you going to announce all your users mailing list subscriptions > in the policy record? If you do, that could be a privacy problem. > > If you don't, then the spammer can add any mailing list header to > the message, and they can drive their truck through this hole. > > Wietse Surely that's OK, if that's the policy. The point is that the recipient must assign reputation to the list, not the original sender. If the list proves trustworthy (presumably it applies its own DKIM sig, or has an SPF pass, and also has a good reputation with the recipient), then the recipient might go on to assess the reputation of the author - on the basis that a trusted list is likely to be making a DKIM assessment of inbound mail. I've come a bit late to this conversation, but it seems to me that the problems under discussion are really all about how a recipient should treat inbound messages. If list managers were routinely testing inbound DKIM and/or SPF, then a list with a good reputation should be able to deliver mail by re-signing and applying SPF. It also seems to me that there must be a difference between "dkim=all" and "dkim=discard". Publishing "discard" should mean that there's no expectation that the sending domain will be sending mail to discussion lists. These domains ought to be reserved for purposes like sending personal banking notifications. I don't think I have any such domains, but I guess I could think of some use cases for a University. Domains publishing "all" ought to be able to get mail through a mailing list. Recipients of such mail that has been corrupted by a list should accept it only on the basis that the list itself has a good reputation, combined with a verifiable DKIM signature, or SPF pass. Simply inserting list-id headers shouldn't be enough. -- Ian Eiloart IT Services, University of Sussex 01273-873148 x3148 For new support requests, see http://www.sussex.ac.uk/its/help/ _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
