Steve Atkins wrote:
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...
In order to protect the paypal.com brand from brand dilution or
phishing you need a way to differentiate the two cases.
+1. It was well establish that there little defense using DKIM, Policy
and anything else for that matter, against domain phishing.
We are talking about direct domain spoofs which does still exist in
high volume. Policy has an immediate protective value for these two
types of direct domain spoofing, not phishing, abuse:
1) Legacy Domain Spoofing
2) 3rd party Signed Domain Spoofing
- Direct Attempt by DKIM exploiters
- Indirect via Exploited Resigners
No one can deny legacy domain spoofing does exist and no one can say
that all bad guys are going to even use DKIM to try to get around it.
Even if they do, ADSP DKIM=DISCARDABLE can protect this as well.
This has been explained repeatedly on this list, and there's been no
credible suggestion that it's not true.
Any no one every deny this Steve.
You can't lump the two - Spoofing and Phishing are two difference
problems.
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.
All any high-value domain that seeks exclusive DKIM signing protect
needs to do is add a DIRECT domain policy.
Will it protect against phishing? No. No one, not even policy people
have ever said it will. But you can't use that to throw out the baby
with the bath room. Spoofing and Phishing are two different problems.
I think you are saying that because you can't protect against a
serious hacker going the extra mile with Phishing, that you shouldn't
even bother with simple common sense domain spoof protection controls.
Its like saying a club bouncer, a bartender or a traffic cop all thinking:
"You know, all are IDS are easily forged, faked anyway.
I'm not going to bother to ask and check it."
Yet, you and I and that white picket fence post knows its all possible
to create fake ids. But I don't think that mean checking should not be
done. If it does mean that, then we have no SPOOF protection as well.
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.
I agree because no one, on all sides, including the policy camp have
every said phishing is addressable with DKIM, POLICY or anything else.
Short of a receiver having a phish database locally or remotely,
whatever, of commonly exploited domains, there is nothing you can do
about that.
But no one ever said policy addresses phishing so please lets stop
using this as a reason to kill policy development that have a clear
and direct high protection benefit against spoofed, not phished, domains.
--
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html