--On 13 October 2009 00:01:05 -0700 Dave CROCKER <[email protected]> wrote:
> > > Steve Atkins wrote: >> The "brand" cannot be protected solely via ADSP, at all, not in any >> manner. >> >> By that I mean that it's possible to protect the byte sequence >> paypal.com to some limited degree, but that that is operationally >> meaningless without any way to distinguish between "paypal.com" and >> "paypa1.com", or between "citibank.com" and "citibankonline.com", > > > If anything, Steve is being generous, because it's actually muss worse > than that... I understand the issue here, but part of the point of DKIM/ADSP is to allow automated systems to assign reputation to an email domain or email address - a byte string. Those automated systems will be able to distinguish between paypal.com (likely with high positive reputation) from paypa1.com (likely to acquire a very high negative reputation quite quickly. So, sure, if the paypa1.com email is delivered, the recipient isn't protected. Except, perhaps if the MUA fails to mark the email as from a trusted source - a bit like the way browsers are beginning to identify web sites with Extended Validation certificates. Furthermore, such systems could be designed to look for close mismatches, using Hamming distance functions, for example. My bet is that paypal don't own any domains with a Hamming distance of one from paypal.com, though they may well own domains with a Hamming distance of three - like paypal.org It might be nice if paypal could publish in the DNS a set of related domains, that it is willing to share the reputation of paypay.com with. Positive reputation could flow from paypal.com to the shared domains, and negative reputation in the reverse direction. > The name variants are one line of attack, with respect to the From: field > address - which is what's being discussed here. > > But then there are all the attacks on the From: field visible name -- > which is all most recipients ever see -- the Subject line attacks and > the Body attacks. None of these is even touched by an ADSP approach. > > When someone asserts that a mechanism offers protection, they are > obligated to account for the cases that are /not/ covered. If they are > diligent, they will then assess the relative costs and benefits of this > protection proportion, versus the unprotected proportion. > > d/ -- Ian Eiloart IT Services, University of Sussex 01273-873148 x3148 For new support requests, see http://www.sussex.ac.uk/its/help/ _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
