I hope to attend in person, barring any volcano's ash plum of course. :^)
The motivation to enhance ADSP is to overcome well established
weaknesses inherent in ADSP's current form. These weaknesses
significantly limit where ADSP might be applied. These limitations also
create the unintended consequence of causing adoption of bad
anti-phishing practices.
Since a principle motivation for ADSP is to assist in mitigating
phishing related abuse, the mailing-list recommendation for phished
domains to use sub-domains with non-restrictive policies is a recipe for
increasing the number of victims, and for increasing the administrative
costs in mitigating abuse. As a community, we can do better.
Not all efforts at combating abuse are based upon profit motives.
Believe it or not, those offering reputation services still confront
litigation issues, even today. In the past, these issues caused our our
free service to become subscription based. In light of the ongoing
liabilities, offering recommendations that presume a sender's DKIM
compliance is even more perilous. Should such a service err on
protecting subscribers, or limit recommendations to vanishingly few domains?
This information MUST come from senders, which is why ADSP was
developed. No reputation service can offer a comprehensive solution,
especially when sending domains are increased in number as a result of
unintended problems caused by third-party services.
The Internet represents a large community of individuals willing to
implement comprehensive solutions able to overcome vexing issues. These
solutions are not always driven solely by profit motives. The TPA-Label
scheme is intended to provide email communities the tools for reducing a
domain's attack surface. ADSP, as currently defined, does just the
opposite. Doing the right-thing with respect to authentication, is a
different criteria than those related to spam. While reputation might
mitigate spam related abuses, fast-flux strategies give a major
advantage to those phishing for victims.
Before ADSP becomes a suitable tool for dealing with this issue, it must
become more comprehensive, and not lead to greater unrestricted
sub-domain use. To avoid this vexing issue, ADSP must include a
third-party authorization scheme. While a provider such as Gmail might
be unable to assert a restrictive ADSP policy, their customers certainly
could. In other words, ADSP could become suitable for any DKIM signing
domain, as determined by the Author Domain.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html