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