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
