ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] list vs contributor signatures, was Wrong Discussion

2010-06-02 13:43:42

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

<Prev in Thread] Current Thread [Next in Thread>