"Steve Atkins" <steve(_at_)wordtothewise(_dot_)com> wrote:
On May 27, 2010, at 7:38 PM, Scott Kitterman wrote:
"Steve Atkins" <steve(_at_)wordtothewise(_dot_)com> wrote:
That should be
Legitimate email from paypal:
72% rejected by ADSP
28% not rejected
Phishing emails using "paypal" in the From line:
39% rejected by ADSP
61% not rejected.
Why "paypal" in the from line and not from payal.com? It sounds like you are
capturing messages unrelated to any ADSP assertions paypal.com might make.
No, I'm capturing (a subset of) phishes that were targeting paypal. That
subset was those that were using the string "paypal" somewhere in the From:
field, either in the local part or domain part of the email address or the
"friendly" from. Some of those would have been rejected by ADSP, some
wouldn't. See the message the one you quote was a reply to for the methodology.
This is just a quick and dirty way to identify a subset of paypal related
phishes, though, as I don't want to grovel through hundreds of thousands of
messages looking for phishes by hand. A more thorough approach would have
found a number of additional phishes that did not have the string "paypal"
anywhere in the From: line, and so which would not have been rejected by ADSP.
In other words, were I more thorough I would have found exactly the same
number of phishes that were rejected by ADSP and I would have found more that
were not rejected.
(If you were to define phishes targeting paypal as "phishing mail that would
have been rejected by ADSP" then that would lead to 100% of phishes rejected
by ADSP and 0% that weren't. That would be nonsensical, though.)
Selecting messages that are by design outside the scope of what ADSP is
intended to deal with to prove ADSP doesn't work is even more so.
ADSP does only deal with exact domain forgery. Some people think that's worth
doing and others don't. The fact that it is not the miracle solution to all
phishing is neither surprising nor particularly interesting.
The working group went through this exact discussion when ADSP was being
developed. The rough consensus of the group was to go forward and unless there
is some new information to cause us to reconsider the decision, hauling the
same arguments out again is just wasting time better spent on other things.
ADSP is not the policy component for DKIM that I would have designed, but it's
the one we have and I'd rather see what can be done with it than rehash
preconceived notions.
Scott K
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html