--On 13 October 2009 00:01:05 -0700 Dave CROCKER <dhc(_at_)dcrocker(_dot_)net>
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