Really? You mean that if you stopped doing this you'd have trillions,
or quadrillions of spams per day instead now? I'm skeptical.
Mike
The vibe I got from a number of administrators I talked to about it was "why
would a standards document assume an IPv4/IPv6 unicast address is a residential
customer with a modem, forcing those with allocations to prove that they are
not residentially allocated rather than the other way around?"Because a default allow policy doesn't work in today's environment.
There are lots of other ways to deny that don't cause massive collateral damage. Allowing IPs with "suspicious" PTRs to attempt a connection doesn't mean their mail is delivered, or even that their connection will succeed. There are better ways to deny.
Blocking generic and residential addresses is the single most effective
thing we've ever done to reduce spam.
Not surprising, but at what cost of false positives? Maybe your organization is different, but the ones I talk to are much more worried about missing a single e-mail than blocking an extra 1,000.
Most legit senders don't want to look like a compromised box in
someone's bedroom anyway.
There are literally thousands of companies who don't grasp the difference, or have little ability to influence their appearance. I listen to the guy in the next cube over say "setup your RDNS" probably half a dozen times a day. He's lucky if they even understand what he said most of the time. Most people just do not grok DNS--even when they're given simple templates to fill out, cut, and paste they still manage to screw it up, or simply ignore it.
The membership of this list probably has one of the highest concentrations of DNS-clue in the world, but it's not representative of most organizations with an e-mail server.
1) Is this really the place to talk about SORBS?
2) Your reply to Dave's post is not useful. It's not even useful if you consider it pure hyperbole for effect. There are many ways to reduce spam, the "single most effective" does not stop even 50%.
3) Should people really argue over what other people do with their own machines? You don't like SORBS, don't use it. Someone you need to talk to likes SORBS, make them stop, or conform. Might as well argue over a website using HTTPS when you don't like encryption.
The vibe I got from a number of administrators I talked to about it was "why
would a standards document assume an IPv4/IPv6 unicast address is a residential
customer with a modem, forcing those with allocations to prove that they are
not residentially allocated rather than the other way around?"Because a default allow policy doesn't work in today's environment.
Blocking generic and residential addresses is the single most effective
thing we've ever done to reduce spam.Really? You mean that if you stopped doing this you'd have trillions,
or quadrillions of spams per day instead now? I'm skeptical.1) Is this really the place to talk about SORBS?
I'm not the one who brought up SORBS. My post didn't even have anything to
do with SORBS.
2) Your reply to Dave's post is not useful. It's not even useful if you consider it pure hyperbole for effect. There are many ways to reduce spam, the "single most effective" does not stop even 50%.
3) Should people really argue over what other people do with their own machines? You don't like SORBS, don't use it. Someone you need to talk to likes SORBS, make them stop, or conform. Might as well argue over a website using HTTPS when you don't like encryption.
Who said anything about SORBS? Not me. Sorry. My post had to do with whether
rDNS is doing much of anything in this day and age. I'm dubious. Spammers don't
seem to have any impediment because on it.
Mike
I don't think the discussion is about SORBS, I think it's about this standards
draft that SORBS points to. Here, I'll lay out what I'm saying simply (and
retitle the thread so the SORBS issue will go away):
1. Your mailserver receives a connection from a previously-unknown relay.
Although this discussion is meta to mail, it's the most prime example.
2. Very quickly, your mailserver must make a spot decision on whether the
connecting IP address is a residential modem or a racked server. This
information might be important in an administrator's decision, via his
rules, to accept or reject any message that relay offers.
(To reiterate: the problem is determination of sender, not an attempt
to determine if the incoming mail is legitimate. This is beyond that.)
3. Currently, the solution is to consult the PTR, which this draft -- which
coincidentally is written by the administrator of SORBS -- recommends.
4. For other reasons laid out in this thread, PTR is not the best choice.
Additionally, administrators of mailservers who have no idea what a PTR
is -- although their entry fee to the Internet mail system is debatable
it will not be discussed here -- are now punished by blocklists like
SORBS and Trend Micro with the simple crime of not knowing to PTR their
mail server with something that screams "static allocation, not CPE".
I note, with a heavy hand, that there are no widely-disseminated
standards governing the reverse DNS of an Internet host other than this
draft, but administrators make decisions on it anyway.
5. What else does your mailserver use? What could it use? Are there any
desirable candidates for a standards-track behavior for determining the
"class" of an IP (i.e., iPhone, home CPE, colo'd server, grid node, and
so on). Should there be?
My original goal here was educational -- I'd like to hear if anybody has
given this question serious pause aside from putting silly restrictions on
what can go in a PTR, and basing a heavy decision on said PTR. Are there
any applications for such a test, outside of mail?
I've apparently hit a nerve, and I'm sorry for that.
JS
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.
It's funny that you say that in reply to Dave's note - I usually wear
headphones in the office so I don't have to listen to Dave in the next cube
saying "fix your RDNS" over and over to clueless admins.. 
4. For other reasons laid out in this thread, PTR is not the best choice.
Additionally, administrators of mailservers who have no idea what a PTR
is -- although their entry fee to the Internet mail system is debatable
it will not be discussed here -- are now punished by blocklists like
SORBS and Trend Micro with the simple crime of not knowing to PTR their
mail server with something that screams "static allocation, not CPE".
Mild correction: it's FAR BETTER to use something that screams
I AM A MAIL SERVER WITH A LEGITIMATE PURPOSE AND A COMPETENT ADMIN
rather than just using yet another generic static naming convention. 
Because using generic static naming is falling victim to the rather
baseless assumption that all statics should be allowed to send mail,
which is just ridiculous. We've got a /27 (we're a web app dev shop) and
only one of those IPs is a mail source, one is a NAT, one is a VPN box,
several others run Web servers and other services, and so could possibly
emit mail but likely only to us, and we can always whitelist if need be.
I assume that the case is similar in other organizations; their static
IPs far outnumber their canonical mail servers.
Of course, I asked for appropriate custom PTRs for all of them, but
still - the point stands, especially for those who think that generic
static PTRs are sufficient for a modern mail infrastructure. I don't
care who your ISP is, I care who you supposedly are, because if I see
that your mail server (or other hosts on your network) are infected,
compromised, or otherwise sources of abuse directed at my network, I
want to deal with /you/, not with your upstream's abuse desk triage.
I note, with a heavy hand, that there are no widely-disseminated
standards governing the reverse DNS of an Internet host other than this
draft, but administrators make decisions on it anyway.
On that and on a wide variety of other criteria, yes.
I've done a little bit of work in the anti-spam area as well (starting
around 1983) and I can tell you that your viewpoint about DULs is
roughly half a decade out of date. With the rise of 100M+ zombies, it
has long since become a best practice to block outright anything that
looks like, smells like, feels like it's not a real live mail server.
(And many things that are.) One of the best ways to do that is to
reject all mail from anything without a PTR, and a lot of things *with*
PTRs matching certain well-known/well-understood patterns.
Hence the work of various DULs, the EnemiesList project, and others.
They have long since proven their marked superiority to other methods
in terms of accuracy, resource cost, maintainability, scalability,
resistance to countermeasures, and other applicable metrics. They're
some of the very best tools we have, and anyone with even a little bit
of clue is using them for all they're worth.
Default-permit mail system policies which don't implement these are
years behind best current practices.
PTR allocation policies which pretend that this doesn't work or shouldn't
work or won't work are years behind best current practices.
As an aside, there is no such thing as "collateral damage" in this
context, because there is no such thing as "damage". This point was
discussed extensively on the IRTF-ASRG mailing list nearly two years ago
in the discussion over Chris Lewis's RFC on DNSBL operational procedures,
and I believe I presented a clinching set of arguments there as to why
that's the case -- certainly enough to get that language removed from
the draft. You might want to read that list's archives to see why
that phrase has absolutely no place in any anti-spam discussion.
I suggest that further discussion of this move to spam-l, where it's
probably much more appropriate than NANOG.
---Rsk
We did stop. We used to maintain our own list. Dealing with it, and the
support issues it caused ate up a lot of time. It stopped about half of
the mess that was offered to us. Right now we're quarantining and
blocking via other means a lot more than we used to.
And no, it doesn't mean we get trillions or quadrillions of spams a day
now. No single method we use stops even 60%. (and probably not even
that.) Now we can point the users at our vendor, and use the time for
other things. We do get more spam, but we're probably coming out ahead
in cost/return sense.
I'll note that we blocked generic names, as well as obvious end user
names.
I'd love a more standard nameing policy.
The original statement is accurate, and becomes nearly an absolute
if qualified with the addition of "...from zombies". This is common
knowledge among everyone with sufficient $clue in the field, and has
been for most of the past decade. Remaining research/discussion/debate
is now focused on how best to enumerate such space, either by PTR or
by allocation. Given that the zombie population continues to monotonically
increase with no sign that the trend will reverse, and given that precious
few owner/operators of such space have taken appropriate, timely and
effective actions to staunch the flow of outbound abuse from the zombies
within their operations, it seems reasonable that this tactic will
remain extremely useful into the forseeable future.
Once again, I direct those interested to the spam-l list (and its archives)
where copious discussion on these points may be found, and is much more
on-topic than here on NANOG.
---Rsk
Well not to drag this into a meta-thread, but you're not the only one with experience. I've been doing this for well over a decade too, so have a great many of my colleagues, not only at my employer, but at competing companies. I can tell you that your view on this is far from universal.
Parties who believe blanket blocking of IP space (sounds very 1999 to me, I was there, I did that stuff) is the best thing ever tend to not have access to high-quality reputation services and/or content-based analysis. See Joel Snyder's comments. BTW I'm not talking about anything Open Source.
There are lots of ways to block a lot of spam, but most of the perceived "low-cost" ways block a non-trivial amount of wanted mail. Call it whatever you like, the fact remains that most organizations that value e-mail as a communication medium do care about missing those wanted messages. If it was as simple as blocking dynamic IP pools and spammy .TLDs, organizations would be doing that instead of paying $$$ for sophisticated services & software.
That's the last I'll say on blanketing vs. intelligent blocking for this thread.
PS We agree on quite a few subjects, just not this one.
That would be fine *IF* SORBS, et. al., actually paid any attention to such things. I have dealt with SORBS several times over the years, and NEVER, EVER, have they given a single shit. Your connection is "ADSL" and therefore "residential"... We were told by the ISP that address range is "residential" -- a verified f***ing lie, btw. The request has to come from the ISP -- which they will ignore as well.
To date, everyone who's ever blocked an email from me due to SORBS DUL, *NO LONGER USES SORBS*. (I also rewrote the sendmail macro to explicitly ignore their spamtrap list as well. It only takes one message, EVER, to get listed forever. And they will not show you the message(s) that got you listed.)
--Ricky
telmnstr@757.org wrote:
Did SORBS really cause you that much pain?
Yes. We purchased colo space for some systems that didn't need high class of service (mostly development systems.) The IP space in a former lifetime was a dialup pool for analog modems.
We of course changed the reverse DNS entries, and did the normal request with SORBS. Nothign really happened. I started looking into it, and finding stories of people doing the mandatory $90 donation to get express attention,
...and at this point we know the poster (like a fair few other in this thread) is either talking c**p or mixing SORBS with some other list. There is NO donation required for non spam listings (a DUHL entry is not a spam listing) and $90 is plucked from thin air... a cursory look at the SORBS website will attest to that.
Michelle
Note: The original poster was noted to have never opened a ticket @ SORBS by one of the staff.. I haven't verified that personally, but it does follow a common theme.. People complain about listings and have subsequently been found to have *not* requested delisting through the correct channel (the SORBS support system)... I wonder how many would get this sort of response (a firey NANOG thread) if they complained their ADSL was broken to the yellowpages sales line...?!?!?
At the same time, I never hear this about spamhaus or outblaze. Go
figure 
Maybe your system is too confusing and you might want to
take a survey and revamp it to something a bit more functional.
Ken Chase wrote:
Anyone got some pointers on how to get off SORBS' Dynamic IP lists?
We've followed their RFC proposed static reverse DNS assignment naming and all
elements of their FAQ.We are not spammers. The /24 in question isnt listed on any RBLs except SORBS DUL.
We've submitted requests in various different formats, but get a robot reply
and -ENOJOY.We've even had our upstream that is listed at the RIR as managing the supernet
of our BGP announced prefixes submit requests to delist for the /24, but
we are only ever replied to by a robot that lists 67.196.137.0/24 as
dynamic except .163 (somehow manually excluded from their db, I think when
they werent adrift in years past). Our upstream's techs are also at a loss now
and suggested I seek arcane clue amongst the sages here.Pointers appreciated.
/kc
OK, following my last post I have been given 4 ticket numbers for the same network. 3 appear to be from Ken using a different email address (hence why we couldn't find a ticket from him.)
Normally I would not post a public response, but this case is what seems to be a reoccurring theme, so maybe it's time to post comment.
Each of the tickets are similar in that they all refer to the same space. All were rejected by the robot with the following text at the end of the reply:
I'm now marking this request as 'answered' as I think there's nothing
more for me to do. If you feel otherwise, please reply to this message
to re-open your ticket. In particular, if you change your rDNS
information.
Each of the 4 tickets (the three by Ken) are all sitting in the state of "Answered" ... so at no point has a human had chance to see the issue and override the bot's decision.
The common a reoccurring issue is the response by the robot has given the next logical step to progress any delisting request (as has been stated here recently, in another thread).. and the requester has either not read the response or chosen to ignore the response or <insert other reason which results in not responding to the ticket>... then the come here complaining about not getting a response from SORBS. The reality is they got a response from SORBS and did not act upon the response. Sorry Ken, this is not having a go at you, but it is a very common theme and deserves airing. Other issues are where the appropriate contact (as listed in the whois record at the RIR) also ignore the same two sentences, get rejected by the robot and choose to log a new ticket only to get the same response over and over again.
Is it bad English? Is it not clear? Can anyone else give better wording that might result in less of an issue? The process is relatively simple:
For fast approval:
Log ticket -> robot checks rDNS for all networks listed in ticket -> robot confirms all space is static and submits the ticket to the removals queue where it is manually checked by a human and processed.
For manual approval:
Log ticket -> robot checks rDNS for all networks listed in ticket -> robot denies delisting request sending response -> OP changes something and replies, just states they are the whois listed appropriate contact, or gives some reason why the robot is wrong and reopens the ticket with the reply -> SORBS volunteer reviews the available information from the robot and the subsequent reply from the OP and manually submits to the removals queue or rejects and gives a human response as to why (eg like with Shaw, Road Runner, Verizon, etc listings) the information is provided by the ISP and any delisting will be reversed within a week.
No NANOG is not about SORBS and SORBS should not really be discussed here, but telling people they would be better discussing it on Spam-L will not help you at all as I cannot post there and consequently I have since unsubscribed, as I have suggested to all my staff. Messaging me directly about listings will not help your case, unless something has gone wrong (and since Jan 09 I have only had one issue where something went wrong in the SORBS systems, all other requests were without tickets or twits that logged a ticket and sent me the ticket number before the robot had replied because they thought they might get special attention.)
The best thing anyone can do is read the automated responses (some are from the system as the ticket is logged, some are from the robots) completely, and act upon what they say as majority of the time this will result in a fast delisting.. Christmas Eve 2009, DUHL delisting requests were happening within an hour of requesting a delisting. My moving internationally and 30 hours in the air have slowed that process, but I intend to get it back to within 60 minute responses again by the end of January.
Michelle
Ronald Cotoni wrote:
At the same time, I never hear this about spamhaus or outblaze. Go
figure
take a survey and revamp it to something a bit more functional.
I have never heard it about Outblaze, but I have heard "at least we get a reply from you unlike with Spamhaus" several times. The only thing I can't work out is why those people never post that publicly... and yet the same 50-100 people keep getting the same attention over SORBS time and time again. I love searching "SORBS Sucks" in Google and counting the number of hits that are actually the same people over and over again on multiple lists (especially Mr "Be good to pigeons".)
The SORBS support system has become more and more stricter because of the people trying to circumvent the process. There are many people that have no problem at all with the SORBS support system so why it is so hard for a few? Perhaps it's because they don't really care about delisting but do care about making noise? (for example there are a number of people on this list that are here only to response negatively to SORBS issues.)
Michelle
I'm now marking this request as 'answered' as I think there's nothing
more for me to do. If you feel otherwise, please reply to this message
to re-open your ticket. In particular, if you change your rDNS
information.Each of the 4 tickets (the three by Ken) are all sitting in the state of
"Answered" ... so at no point has a human had chance to see the issue and
override the bot's decision.
Is it bad English? Is it not clear?
No, it is not clear.
Can anyone else give better wording
that might result in less of an issue?
"Please reply to this message to reopen your ticket and escalate your
case to a live human being."
Regards,
Bill Herrin
Fair enough, but it wasnt just me.
I have the customer who submitted his own tickets as well, as well as NAC.net
who has admins (an email admin, actually), who seems to know his way around RBLs
and the current state/reputation/happenings in the spam/RBL/mail world.
Customer has posted these tickets:
260573, 260695, 261026, 261204, 261325, 261377, 261624
and the last ticket I posted was from NAC's admin, who received and acted on replies
too.
That makes 3 semi-clued people who found your system somewhat confusing (+1
interested party @coplanar = 4). The ironic thing is that if you make it
any clearer, spammers may also figure out how to clear their networks easily
as well from your list. 
So I can see the reason for not doing so to some
extent.
At any rate, thanks for the pointers, I think that many others on Nanog will also
find this useful as I had many private replies indicating frustration. I will attempt
to follow your instructions closely, get the block rescanned now that it matches
your RFC-proposal requirements.
/kc
Is it bad English? Is it not clear?
No, it is not clear.
It's perfectly clear.
Can anyone else give better wording
that might result in less of an issue?"Please reply to this message to reopen your ticket and escalate your
case to a live human being."
You:
"Please reply to this message to reopen your ticket and escalate your case to a live human being."
And now SORBS:
"If you feel otherwise, please reply to this message
to re-open your ticket."
Try as I might I really can't see what is not clear here...
B