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: accou...@big-bank.com > From: some...@big-isp.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