On 10/27/10 8:53 PM, Hector Santos wrote:
The lack of focus for 1st party domain protection is what allowed this
issue to fall through the crack. We tried our best to make DKIM a
pure signing mechanism with an open ended "implicit policy" of
unrestricted resigners, remolding the specs with out of scope "wink
wink" design goals. MLM "allowance" or "tolerance" became a dominant
goal over the principle benefit DKIM can provide - 1st party DOMAIN
protection.
The solution is an integrated solution. DKIM itself can not solve
this. At this point, what's missing are HANDLING provisions for DKIM
verifiers. A real POLICY protocol with 3rd party considerations is
really the only thing that can help resolve this problem. Even
Reputation Vendors can help here but they need to support POLICY too.
Instead, the pressure has been to eliminate it.
Agreed. But additional handling provisions are meaningless without DKIM
PASS offering an actionable state. Unless trivial exploits allowed by
multiple (singular) header fields are assured to receive PERMFAIL, DKIM
will not offer a basis for message handling or annotation.
There is ongoing effort within the TPA-Label scheme. Several companies
also want an authorized third-party reporting mechanism as well, which
can be combined with the TPA-Label extensions. Third-party information
needs to be made generally available before such policy assertions
become easy for typical administrators. The difficult policy issues
involve multiple domains when seeking meaningful and concise handling
decisions without disrupting legitimate message sources. The relatively
small number of legitimate sources makes this a tractable problem,
especially for those who track these sources.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html