On Wed, Oct 20, 2010 at 01:41:03AM -0700, SM allegedly wrote: > At 17:53 19-10-10, Mark Delany wrote: > >In a DKIM world a list server could reasonable use DKIM to bypass this > >"confirm" sequence and make your life a bit simpler. Perhaps it relies > >on Authentication-Results or somesuch. In any event such a list server > >is actually *more* vulnerable than it is today if we let thru bogus > >payload that appear to be valid. > > According to Section 7 of RFC 5672: > > "For DKIM processing, the domain name portion of the AUID has > only basic domain name semantics; any possible owner-specific > semantics are outside the scope of DKIM." > > Furthermore, in Section 8: > > "A module that consumes DKIM's mandatory payload, which is the > responsible Signing Domain Identifier (SDID). The module is > dedicated to the assessment of the delivered identifier. Other > DKIM (and non-DKIM) values can also be delivered to this module as > well as to a more general message evaluation filtering engine. > However, this additional activity is outside the scope of the DKIM > signature specification." > > Based on the above, I don't think that a list server could use DKIM > to bypass the "confirm" sequence.
Well, that's "should". It also assumes that all subsequent users of DKIM bother to read and obey. It also assumes that future users of DKIM won't get inventive and use DKIM in ways that we can't even imagine. I think that undersells DKIM and future users. Just ask the inventors of DNS whether they thought we'd be using it the way we are... or whether we're using it the way they intended. Mark. _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
