ietf-dkim
[Top] [All Lists]

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

2010-06-02 14:34:29

On Jun 2, 2010, at 2:41 PM, Steve Atkins wrote:


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.

I don't think you are following me... the receivers who are performing ADSP 
look-ups and enforcing "discardable" would have blocked a ton of that email you 
are reporting would have made it through.


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.

...and I wasn't going to mention that I tried to work with you off-list to get 
more information about your phish from paypal.net but you didn't respond.   If 
you get a chance, please do send that along.


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.

As I've reported before, we have over 100 millions reasons (blocked attacks 
from our registered domains) why you are wrong about this assertion.


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.

You have this backwards.  Major brands register cousin domains for more reasons 
than phishing.  This practice pre-dated ADSP and it will continue with or 
without ADSP.  It's simply an operational fact that is relevant to any debate 
about how ADSP can/should be used.


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

and I understand you wanted to report statistics to discredit ADSP... actually 
I don't understand that but it is certainly consistent with your arguments

- 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.

but your processing assumptions about what would get through vs. what would 
bounce was wrong.


These statistics are quite valid, and reasonably representative.

now I'm just repeating myself...

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)..

yep, that's rather significant.


So rather than attacking the statistics that demonstrate that your current 
usage of ADSP simply doesn't work for it's stated purpose

it works quite well actually, as a component to a multi-part strategy.


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.


because MLM's break DKIM signatures, it does help the immediate pain to move 
employee mail to non-ADSP=discardable domains... like I have.

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.


somewhere in there is a nugget of a good idea for a Senders BCP.

_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

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