on Tue, Jan 12, 2010 at 01:31:06PM -0500, Jed Smith wrote:
Steven, take it easy please.
Given the first few replies I received, allow me to clarify, now that I've successfully hijacked the thread and apparently angered the anti-spam crowd:
Oh, I'm not angry, if anything I'm disappointed by the massive ongoing failure on the part of some of the folks responsible for PTR naming to deal with the FACT that people are ALREADY using PTRs to discriminate against probably infected spam-sending hosts. And the willingness of so many to argue against the adoption of sane naming conventions. And the amount of time that gets spent by people offering up their opinion on whether PTRs have any value at all (they do) and suggesting that maybe we should just eat all the abuse, forever, without making any efforts to stop it at our perimeters. But I've come to expect it from nanog. It happens that the doc that M. Sullivan wrote contains certain recommendations. It's not the only draft to do so. It doesn't matter to me what people do, as long as they're consistent (unlike, say, vsnl.net.in), as long as they don't mix dynamic and static naming (like RIMA-TDE), as long as it's not idiotic (like volia.net) and as long as they do /something/. But I've already tracked almost 50K naming conventions over the past six years or so; *I* don't *need* you to be sane or to agree with me or M. on specific tokens you should use, or to even agree that PTRs make a reliable indicator of legitimacy for SMTP emitters. That boat has sailed, that dog's been hunting for *years*, it's not an issue. Major AS appliance and AV vendors are already using these practices, period.
Honestly, I feel that PTRs are the least reliable way to make such a decision.
Well, be that as it may, other people don't share that opinion. And they're running mail servers, or writing software that runs antispam appliances, or they're sharing datasets on how to block mail from generics on lists like spam-l. It's ALREADY HAPPENING and has been for several years. To be more specific - I've looked at several hundred thousand IPs with PTRs, and analyzed and classified their naming conventions, to the tune of ~48K patterns in ~26K domains, over the last six years. PTRs are a very useful tool for SMTP, and a very useful tool for finding bots. Period. Yes, many PTRs are too generic to say with certainty "this IP is a dynamic/residential host", but many are not (approximately 13K out of that 48K are dynamics, 12K are statics, and others are generic - 13K or so - and still others are weird mixes like NATs and resnets). Why? Because other netops have discovered that providing a degree of transparency is reducing their abuse load, because it allows everyone else to reject from their dynamics. Helping Spamhaus PBL, SORBS, and everyone else classifying /your networks/ make the right decision is important, whatever your opinion of whether trusting PTRs is "smart".
Depending on the chain of delegation, a server operator may not have access to modify his PTR record and might not be able to change it.
And that's the rest of the network's problem how?
Several operators have annoyingly odd delegation patterns.
So?
PTRs are just bad news for any kind of useful decision on, other than "PTR-matches-A". Given the amount of IRC abuse PTRs have seen, the consequential abuse of IPv4 allocation to support exotic PTRs, and the resulting limitation of PTR alteration that many providers practice I just don't like PTRs overall for anything meaningful.
So, because a few blocks have silly.irc.scrip.kiddy.rdns the rest is not to be trusted? I've got 48K patterns against your occasional IRC script kiddy abuse that say otherwise. If a host wants to claim in SMTP that it's 18715194033.user.veloxzone.com.br [187.15.194.33] and I know that IP is residential, I have no reason to doubt it. Even if (as in this case) the PTR doesn't reverse-resolve. Even more so, I'd say. And even more if (as in this case) that host tried to send me nine spams (six to forged/bogus addresses based on mine) in the past three minutes.
I also disagree with space being assumed dynamic unless it is declared static -- helpfully, I have been reminded that consumer CPE equipment is a large number of IPv4 endpoints, but I still think space should be assumed static unless declared dynamic. The burden really should be upon the providers of dynamic services to inform us that their allocations are a dynamic pool; good luck with this, however.
I agree with you completely. Fortunately, genericity (rather than "static" versus "dynamic") matters even more. Yes, we classify patterns as applying to static hosts if that's what we can determine. But we score static generics as well, and treat them as suspect. And so do a lot of other folks, either using our data or otherwise. You're in a different position than most of the end user ISPs here; as a provider of web hosting and colo, you're going to have to deal more with scumbag snowshoe spammers and their ilk, and appear to be doing a decent job of it, based on my logs. /ll/maillog.24.gz:Dec 19 11:53:11 tabasco sendmail[32510]: nBJGqsYW032510: from=<no-reply@grownetlowworld.net>, size=0, class=0, nrcpts=0, proto=ESMTP, daemon=MTA, relay=li143-113.members.linode.com [109.74.196.113] /ll/maillog.24.gz:Dec 19 17:28:44 tabasco sendmail[1554]: nBJMSQqv001554: from=<no-reply@illtakeworld.com>, size=0, class=0, nrcpts=0, proto=ESMTP, daemon=MTA, relay=li143-113.members.linode.com [109.74.196.113] /ll/maillog.24.gz:Dec 19 20:21:02 tabasco sendmail[16525]: nBK1KiD6016525: from=<no-reply@christiansoftwarestore.com>, size=0, class=0, nrcpts=0, proto=ESMTP, daemon=MTA, relay=li143-113.members.linode.com [109.74.196.113] /ll/maillog.25.gz:Dec 18 10:19:13 tabasco sendmail[8583]: nBIFItLC008583: from=<no-reply@lowpriceprogram.net>, size=0, class=0, nrcpts=0, proto=ESMTP, daemon=MTA, relay=li130-51.members.linode.com [69.164.215.51] /ll/maillog.25.gz:Dec 18 10:30:17 tabasco sendmail[8996]: nBIFU0qr008996: from=<no-reply@lowpriceprogram.net>, size=0, class=0, nrcpts=0, proto=ESMTP, daemon=MTA, relay=li130-51.members.linode.com [69.164.215.51] /ll/maillog.25.gz:Dec 18 12:03:00 tabasco sendmail[14154]: nBIH2gO3014154: from=<no-reply@lowpriceprogram.net>, size=0, class=0, nrcpts=0, proto=ESMTP, daemon=MTA, relay=li76-167.members.linode.com [74.207.234.167] Fortunately, we block all mail from hosts matching that pattern: li[0-9]+\-[0-9]+\.members\.linode\.com because in our opinion, generic / webhost rDNS is far more likely to emit spam than legit mail /for our users/. Others may score on such a pattern, others still may accept it and flag it for the spam folder, approaches vary.
Let me reiterate: I'm not disputing the challenges that network operators face with network abuse, I am simply disagreeing with this draft, its authorship, the sour taste you get from reading it because it's so far past expiration, and its motives in current practice. It's akin to me disagreeing with daylight savings time because it tries to fix energy consumption from lighting.
Fair enough. -- hesketh.com/inc. v: +1(919)834-2552 f: +1(919)834-2553 w: http://hesketh.com/ antispam news and intelligence to help you stop spam: http://enemieslist.com/