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
