[121183] in North American Network Operators' Group
Re: SORBS on autopilot?
daemon@ATHENA.MIT.EDU (Steven Champeon)
Tue Jan 12 15:25:56 2010
X-Received-From: schampeo@tabasco.hesketh.com
X-Delivered-To: <nanog@nanog.org>
Date: Tue, 12 Jan 2010 15:25:12 -0500
From: Steven Champeon <schampeo@hesketh.com>
To: nanog@nanog.org
Mail-Followup-To: nanog@nanog.org
In-Reply-To: <EC670BD6-75B4-4916-889C-4F07E576E6D8@jedsmith.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
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/
