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