Douglas Otis wrote:
I'm having trouble parsing that. Please propose alternate text, or
show an example of what you're describing.
I'll repeat the example given previously. The multiple listing of a
header in the h= parameter can not mitigate exploitation of DKIM PASS
results where a valuable domain is prefixed to that of large domain.
The large domain is unlikely concerned by possible presence of a
pre-pended header field, where their decision not to include multiple
listing for a message clearly not compliant with RFC5322. In other
words, this leaves DKIM results open to exploitation.
From: accounts(_at_)big-bank(_dot_)com
From: someone(_at_)big-isp(_dot_)com
DKIM-Signature: h=from, d=big-isp.com, ...
Reputation can not fix this problem. Fobbing this onto the consumers of
DKIM results goes against the goal of increasing trust in email, and
against the spirit of doing our best at providing accurate results.
Let's fix our mistake.
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.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html