Michael D., The key point that is being missed here is that doesn't matter if we all agree to add 3rd party or mailing list support to an extended RFC 5617 policy protocol. If resigners are going to be exempt from any mandate to support it, it will remain to be conflict with receivers.
Remember that is the key concern and issue here. Even if your DKIM=except-mlist proposal was accepted, endorsed, standardized and implemented by domains by exposing this domain policy to the world, if resigners continue to ignore it, the problem remains. The fundamental question is whether resigners MUST|SHOULD support RFC 5617 and/or RFC 5617bis. -- HLS Michael Deutschmann wrote: > On Sun, 11 Oct 2009, Dave CROCKER wrote: > >> Whatever the semantics that you have in mind, the underlying question is who >> will adopt it and what is your basis for claiming they will adopt it? The >> next >> question is whether the answers to the first question justify the >> considerable >> costs of pursuing this suggestion. > > At the sender side, dkim=except-mlist would be very attractive if the Levine > interpretation of dkim=all stands. No large ISP could deploy the Levine all. > But as a practical matter, any organization with DKIM-supporting smarthosts, > that already uses SPF's "-all", could deploy dkim=except-mlist at minimal > risk. > > At the receiver side, it's a little less useful, since no means is given to > tell whether a message is exempt mailing list traffic or must-be-signed > normal mail. Hence big ISPs are forced to accept some false negative risk by > treating except-mlist as unknown. > > However, for people like myself who have whilelisted all incoming mailing > lists, except-mlist would be so much more helpful than unknown. > > ---- Michael Deutschmann <[email protected]> > _______________________________________________ > NOTE WELL: This list operates according to > http://mipassoc.org/dkim/ietf-list-rules.html _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
