On Oct 12, 2009, at 10:14 PM, hector wrote:
John R. Levine wrote:
Shorter summary: The WG charter says there should be
Yes, there was considerable naive optimism in the charter.
We all agree that it would be great to have a scheme to spoof-proof
mail.
But ADSP isn't it, for the reasons we've all gone over,
which were?
See below.
no matter how much we might wish that it were.
-1. The only wish I have is that stop injecting misinformation.
Any domain that publishes a DKIM=DISCARDABLE and for any receiver that
supports ADSP will immediately protect the Author Domain and the
receiver system from further abuse from:
1) ALL legacy (non-signed mail) DOMAIN spoof attempts at
the receiver.
1) All 3rd party signed mail NOT EXPECTED by the Author Domain
regardless if its was a malicious reply or a stupid list
server ignoring RFC 5617.
Both are huge immediate payoffs for the domain and receiver. To deny
this high benefit is being intentionally ignorant.
To recap, for those who are just joining us, or who haven't been
paying attention...
There are two entirely separate things connected to the sender domain
that one might consider protecting. One is the byte sequence used in
the domain name. The other is the "brand".
The byte sequence can be protected (sort of) via ADSP, but has close
to no value for brand protection or phishing protection.
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", including more
opaque homoglyph domain names based on non-ascii character sets, and
so on and so forth. Unicode technical report #36 is well worth a read
for anyone unfamiliar with the homoglyph issue.
paypa1.com can be protected using DKIM and ADSP in any way that paypal.com
can, so if ADSP can make paypal.com a "safe" or "unforged" or "not a
phish" domain then it can do exactly the same thing forpaypa1.com.
In order to protect the paypal.com brand from brand dilution or
phishing you need a way to differentiate the two cases.
This has been explained repeatedly on this list, and there's been no
credible suggestion that it's not true. ADSP can protect byte
sequences. But protecting byte sequences cannot, in itself, provide
much in the way of brand protection or anti-phishing functionality.
As a rule of thumb, if you are going to assert that any protocol will
protect the "paypal" brand you need to demonstrate that the protocol
can return a binary "good" vs "bad" result, and that that protocol
will return different results for "paypal.com" and for "paypa1.com".
DKIM cannot do that. Nor can ADSP. Therefore, neither protocol can
provide any brand protection, nor any phishing protection.
It's possible (likely, in fact) that a protocol that uses DKIM or ADSP
as part of it's implementation could provide some level of brand
protection, but discussing just the ADSP or DKIM part in the context
of phishing or brand protection without discussing the section of the
protocol that actually provides the brand protection is simply wasting
everyones time.
Cheers,
Steve
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html