[ietf-dkim] Resigner Support of RFC 5617 (ADSP)
gmail.sant9442 at winserver.com
Sun Oct 11 21:32:56 PDT 2009
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.
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
> 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.ocis.net>
> NOTE WELL: This list operates according to
More information about the ietf-dkim