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
