On Jun 2, 2010, at 10:59 AM, Brett McDowell wrote:
On May 28, 2010, at 1:08 AM, Steve Atkins wrote:
Paypal is rather a special case, as they actively register
many, many domains in a lot of TLDs that contain the word
paypal or some misspelling of it, both proactively and in
response to enforcement. I didn't consider those domains
as triggering an ADSP rejection for a number of reasons.
One is that many (most?) of them would have been acquired
by paypal though enforcement action after the phishes were
sent, and the other is that it's a behaviour (registering a
huge number of domains purely to deny them to others)
that's atypical and that doesn't scale.
Havning said that, I did spot check quite a lot of the phishes that
I'd tagged as "not rejected" and the vast majority weren't
using domains I'd expect paypal to have proactively reserved
(paypal.net, for instance) - they were mostly using the word
"paypal" in the friendly from, the local part or a subdomain of
the domain part. Of those that weren't of that form many were
things like "@paypal-access.com" and suchlike. So I think those
two numbers are likely accurate to within a few percent or better.
Your numbers were so far off from what we see that I was perplexed, but now
it's clear why.
In reality we do register many of the domains you assumed we don't (like
paypal.net) and we are not unique in that practice. We have over a thousand
of these domains parked.
The result of this simple error in assumption has skewed your data to the
point where it is no longer representative.
There's no error in assumption. The data is fairly accurate as measured (and
also reasonably representative of the behaviour of a mixed-use domain, I
think).
First, as I said above
they were mostly using the word
"paypal" in the friendly from, the local part or a subdomain of
the domain part
... in other words your argument doesn't apply at all to most of the phishing
email that ADSP failed to deal with.
Second...
steve$ host -t txt _adsp._domainkey.paypal.net
_adsp._domainkey.paypal.net has no TXT record
steve$ host -t txt paypal.net
paypal.net has no TXT record
... I wasn't going to mention it, but you brought it up. The MX for paypal.net
will also give a 2xx response to any RCPT TO in the paypal.net domain.
Third, as I mentioned above, even if you were publishing ADSP records for
lookalike domains, most of those lookalike domains appear to have been acquired
after enforcement of a phishing issue - meaning that there would have been no
ADSP records when the phishing mails were sent, and your ownership of them now
is irrelevant.
Fourth, as I mentioned above, even if all you said was valid, registering
thousands of domains in order to make ADSP sort-of work against phishing isn't
something that scales, either in terms of domain name system nor the expense.
If ADSP requires users to spend tend of thousands of dollars a year to maintain
domain registrations in order for it to have a significant effect on phishing
then it's not something that's really going to scale to more than a handful of
senders.
I feel compelled to point out this error since several people on the list
have been quoting your data since you circulated it and are likely to draw
erroneous conclusions from it.
I understand you want to discredit the statistics - they show that as measured
at my inbox, based on paypal related email, ADSP dkim=discardable as currently
used by PayPal to combat phishing is significantly less useful than flipping a
coin. 72% false positive, 61% false negative.
These statistics are quite valid, and reasonably representative. The only
non-representative thing about them is that they're measured at my mailbox,
rather than at a consumer mailbox of a user who has no interaction with PayPal
other than transactional and bulk email (which is a big difference, sure, but
it seems unlikely paypal would want to drop all usage of paypal.com other than
for their bulk mail)..
So rather than attacking the statistics that demonstrate that your current
usage of ADSP simply doesn't work for it's stated purpose it would be better to
concentrate on fixing the serious issues that those stats demonstrate. I'd
start with the hideously high false positive rate, as that's an easier thing to
fix than the hideously high false negative rate.
We've already discussed some ways to improve the false positive rate
(dedicating entire domains to B2C bulk mail rather than mixed use, rewriting
every mailing list manager in the world and so on). Constraining ADSP usage to
domains that are solely used to send bulk email to consumer ISPs strikes me as
something that would be acceptable to many potential users, and would avoid
most of the false positive issues.
Cheers,
Steve
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html