ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Proposal for new text about multiple header issues

2010-10-28 13:46:35
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