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 <michael(_at_)talamasca(_dot_)ocis(_dot_)net>
_______________________________________________
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