SORBS on autopilot?

Mailman List Mirror (Read Only)
1

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

2

Hmmm, probably something to do with your "reverse" naming convention:

host 67.196.137.1
1.137.196.67.in-addr.arpa domain name pointer
H1.C137.B196.A67.tor.colo.heavycomputing.ca.

host 67.196.137.163
163.137.196.67.in-addr.arpa domain name pointer sizone.org.

host 67.196.137.16
16.137.196.67.in-addr.arpa domain name pointer
H16.C137.B196.A67.tor.colo.heavycomputing.ca.

host 67.196.137.162
162.137.196.67.in-addr.arpa domain name pointer
H162.C137.B196.A67.tor.colo.heavycomputing.ca.

IP 67.196.137.163 appears to actually have a "name" and everything
else has Hnnn.C137.B196.A67.tor.colo.heavycomputing.ca (where nnn
is the fourth octet IP).

3

Have you tried all 3 of the routes listed at http://www.au.sorbs.net/faq/dul.shtml ?

Something they don't tell you on the web page is that they ignore TTL and cache your DNS for a relatively long time. If you tried for automated removal and your rDNS wasn't SORBS-compliant, automated removal isn't going to work for some number of days (I forget how many) even after you have made your rDNS SORBS-compliant.

67.196.137.160 H160.C137.B196.A67.tor.colo.heavycomputing.ca.
67.196.137.161 H161.C137.B196.A67.tor.colo.heavycomputing.ca.
67.196.137.162 H162.C137.B196.A67.tor.colo.heavycomputing.ca.
67.196.137.163 sizone.org.
67.196.137.164 H164.C137.B196.A67.tor.colo.heavycomputing.ca.
67.196.137.165 H165.C137.B196.A67.tor.colo.heavycomputing.ca.
67.196.137.166 H166.C137.B196.A67.tor.colo.heavycomputing.ca.

With rDNS like that...good luck. Go read

http://tools.ietf.org/id/draft-msullivan-dnsop-generic-naming-schemes-00.txt

change your rDNS, wait a few days, and maybe you'll have a chance.

4

Anyone got some pointers on how to get off SORBS' Dynamic IP lists?

Our solution was to find new IP space. It was hopeless.

5

Did SORBS really cause you that much pain?

I ask because the other possible solution is enough people do not find new space that people using SORBS stop using SORBS.

6

host 67.196.137.1

  >1.137.196.67.in-addr.arpa domain name pointer
  >H1.C137.B196.A67.tor.colo.heavycomputing.ca.

Yeah I didnt make the .colo. up, it's in their proposed-RFC document in section 6.3.
They even go so far as to use the word MUST w.r.t. 'colo' in YELLCAPS:

http://tools.ietf.org/id/draft-msullivan-dnsop-generic-naming-schemes-00.txt

  >host 67.196.137.163
  >163.137.196.67.in-addr.arpa domain name pointer sizone.org.

This one was manually delisted a while ago. I have other hosts in there that have
proper custom-reverses such as .188 (which is the customer of mine which wants
off, but we cant get off.) He's had his custom name in there for months. Doenst
seem to help.

  >Have you tried all 3 of the routes listed at
  >http://www.au.sorbs.net/faq/dul.shtml ?

Yes.

  >Something they don't tell you on the web page is that they ignore TTL and
  >cache your DNS for a relatively long time. If you tried for automated
  >removal and your rDNS wasn't SORBS-compliant, automated removal isn't
  >going to work for some number of days (I forget how many) even after you
  >have made your rDNS SORBS-compliant.

It's been 5 days since I changed from a generic naming scheme (which was the above
minus the word colo) to adding in the 'colo'. Maybe the .tor. extra subdomain
is hurting somehow - the feedback loop between executing and testing results is
painfully long, and hard to tie down cause and effect.

I see our listing is also dated as an Aug 29th test, Im not sure how to get them
to re-test the block despite the 're-test' guidelines on their pages.

  >67.196.137.165 H165.C137.B196.A67.tor.colo.heavycomputing.ca.
  >67.196.137.166 H166.C137.B196.A67.tor.colo.heavycomputing.ca.
  >
  >With rDNS like that...good luck. Go read
  >
  >http://tools.ietf.org/id/draft-msullivan-dnsop-generic-naming-schemes-00.txt

Exactly. Section 6.3, though with the .tor., perhaps Im not allowed to
indicate with a STATIC NAME where the colocation is, and perhaps I have to
remove the H/C/B/A as well. Guess ill try and just wait another 4-8 days before
guessing that's not working.

  >change your rDNS, wait a few days, and maybe you'll have a chance.

Have, maybe not enough days though. Hard to tell, which is my whole complaint.
But getting this working would also help spammers, I suppose is their refrain.

Ill try to be extremely literal about the non-RFC and see where that gets me.
Thanks.

/kc

7

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 still not getting attention (so they were reversing the paypal payments and such.) After reading all this crap, I pushed our provider, they couldn't get response from sorbs, so we ended up relaying some of the traffic through our ISP and other traffic through our mail servers that are in a better data center.

We had ZERO problem with Spamhaus. They were cool. Fast. Worked.

The problem of course is that customers that don't know any better use mail servers that are setup for SORBS. Trying to explain it to non-tech folks is futile.

The people that run SORBS are obviously bored with the project, and it should die.

I ask because the other possible solution is enough people do not find new space that people using SORBS stop using SORBS.

That's tough because the people that generally are using mail servers that use SORBS don't know better. They have to ask their providers, etc.

8

"me too"; for 2 of my old (smaller sized) customers in the last 4 or 5
month.
Nothing seemed to work and the immediate financial losses rapidly hit
over 10k Euros in both cases, so switching was by far the easier
option.
I was amazed, but it definitely worked, I'll grant them that.

Both were "normal" and non-spammy setups, correctly configured and well
run by experienced netops. They just figured it was faster/safer
(financially) to move, all things considered.

Caused a panic at the time but until it happens again, 100% success :slight_smile:

Gord

9

Usually that's the easiest path. All it takes is asking the site using SORBS to do a few Google searches.

There are much better options out there than SORBS. Why anyone thinks it's a good idea to cause that much collateral damage is beyond me.

10

SORBS is a joke, always been a joke, and always will be a joke. I'm quite saddened by the fact an entity actually provided financial support to keep it going. The internet community would have been better served had they just went away.

11

SORBS appeared because someone was upset when the widely reviled ORBS
decamped. If SORBS went away there'd just be MORBS.

All the same, it's disappointing to see the SORBS DUL fall into
disrepair. Although not the focus of sorbs' operator, the DUL *was*
one of the more useful lists they published.

Regards,
Bill Herrin

12

At the risk of hijacking the thread, is this draft considered to be of
importance outside of SORBS' domain at all? When handling a /24 that ended up
on the DUL -- I feel this thread's pain -- I made the case that this draft
expired years ago by the book and never got any further. The DUL companies like
SORBS, Trend Micro, et. al. all point to this document as justification for
their practices, however; wouldn't that be considered violating it, given the
preamble on page 1?

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?"

If it remains the magic document to get SORBS to pay attention to you, and
nothing more, that would be ideal.

JS

13

Sure, it's expired and never made it to RFC status. But are the "DUL"'s really pointing at it as justification for their policies, or simply pointing to it as a handy place to find a set of reasonably sensible suggested practices for DNS naming schemes. If there's another similar document, I'm not aware of it.

I don't know that following the schemes the draft proposes is required for keeping IPs off any "DUL", but I sure wish people would at least read it and consider some of the ideas presented...namely that their DNS naming scheme should clearly indicate an IP's purpose, at least if they want that IP to be useful for sending email.

For example, take the following IPs and their PTRs

70.42.226.181 sm-70-42-226-181.quepasa.com
78.228.245.8 mad26-1-78-228-245-8.fbx.proxad.net
83.185.129.102 m83-185-129-102.cust.tele2.se
118.137.228.242 fm-ip-118.137.228.242.fast.net.id
189.84.86.106 189-84-86-106.marinter.com.br

All of them have recently tried sending mail. How many are mail servers? As the vast majority of spam now comes from bot-infected end user systems, it's increasinly important to be able to easily differentiate mail servers from !mail servers. rDNS is a cheap and easy (or at least it can be if the provider chooses) way to do it.

Those who choose to ignore the ideas presented in draft-msullivan-dnsop-generic-naming-schemes-00.txt do so at their own peril.

14

What percent of allocated globally routed IP addresses are residential endpoints,
and what percent are in data centers? What's the better base assumption if
your goal is "I don't want to talk to address ranges that are full of botted
boxes"? There's a *reason* why "default deny" is a well-known security policy.

15

Well, of course. Any idiot can tell just by looking at any PTR that the
IP to which it corresponds is obviously an IPv4 unicast address! I think
they teach that in elementary school now. I know I got high marks on how
to identify mail sources hidden behind NATs, ISP-outsourced university
residential network blocks, and snowshoe spammers using burner domains
with hostnames "borrowed" from real hosts in other domains. But there
was this one kid in my class who simply couldn't see when a host with a
IP-derived, hexadecimal generic name was obviously a broadcast address.
Poor guy. Even when it emitted spam he had trouble seeing that it wasn't
actually possible, because clearly the PTR is always correct.

OTOH, those of us who were out sick when they dealt out the magic PTR
meaning decoder rings need a little more help. If I had my way, all PTRs
would be clear, unambiguous strings of tokens that indicated their use,
their assignment type, the technology or technologies in use, and so on.

In reality, we have names like these to contend with (naturally, this
example's IP whois simply indicates it's part of a /16):

183.87.5.131.static-dynamic.nivyah.com [183.87.5.131]

And if you're trying to classify such naming conventions, as I do with
my Enemieslist project, or if you're trying to build and/or maintain a
DUL, as Michelle does, well, that sucks.

It's far better when the naming is clear, eg

u1524.spam-source.sprintnet.ru [81.22.1.89]
n081022008237.avoid-mail-from-theese-hosts.sprintnet.ru [81.22.8.237]

or, more informatively:

host-79-141-236-93.dynamic.pptp.planeta.starnet.ru [79.141.236.93]
host-94-102-86-87.static.pppoe.planeta.starnet.ru [94.102.86.87]

or, because there's always a joker (both names have since been updated):

alameda.net.has.not.owned.this.ip.for.more.then.four.years [209.0.51.16]
this.ptr.is.named.in.honor.of.arin.nac.net [66.246.175.3]

(heh)

just to pick a few. At the very least, customer-assigned blocks ought to
have a SWIP and a comment showing whether they're dynamic or static,
residential or business class, and so forth. A surprising example, given
the paucity of such examples in the .pl TLD, is dialog.net.pl, which does
exactly that:

inetnum: 87.105.24.0 - 87.105.24.255
netname: DIALOGNET
descr: Static Broadband Services
descr: Telefonia Dialog S.A. - Dialog Telecom
country: PL

inetnum: 62.87.215.0 - 62.87.215.255
netname: DIALOGNET
descr: Dynamic Broadband Services
descr: Telefonia Dialog S.A. - Dialog Telecom
country: PL

So, if the Poles (well, some Poles) can do it, why can't we simply end
the endless back and forth over why SORBS is evil, and start adopting
sane and clear naming conventions for PTRs? Given how easy it is to
modify a $GENERATE statement, I should think you've spent far more
energy on arguing about why you're being wronged than it would have
taken to fix your problem.

16

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:

I am quite aware of the problem and do not disagree that there needs to be a way
to identify what IP endpoints are residential CPE. I simply have some problems
with /this/ current incarnation of a best practice, and I was querying whether
it had applicability outside of the SORBS/Trend Micro world.

Honestly, I feel that PTRs are the least reliable way to make such a decision.
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. Several operators
have annoyingly odd delegation patterns. 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.

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.

Getting a standards-track solution that is reliable, cost-effective for home
Internet providers to get on board with, and that has very little wiggle-room
for discretion (this current incarnation has quite a bit) is necessary for me to
be on board with such classification techniques. That said, I am not the guru
that others on this list are and I am unprepared to present an alternative; I am
simply pointing out that I'd like to see an alternative.

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.

JS

17

I wouldn't say that necessarily accurate. I could be considered part of the "anti-spam crowd", seeing as that's my line of work.

I think DULs are a really dumb way to block spam. Making a binary decision off of information that's wrong as often as it's right it's a great way to create collateral damage and just generally cause more headaches for everyone. Sure, you could take PTR content into account as _part_ of your decision on how to treat incoming e-mail (or connections, for that matter), but it should never be the _whole_ decision.

Keeping track of observed behavior is much more indicative of whether an IP is going to send you spam than just assuming all IPs are dynamic until proven otherwise (through some laborious 12-step process, possibly including bribes^H^H^H^H^H^Hdonations). There are several enterprise-class, best-of-breed vendors using the former technique rather than the latter. I think you'll find it's low-end, unsophisticated outfits who use the latter method.

Yes PTRs should be more accurate and informative, but very often the people standing up mail servers aren't the people who have control over the DNS and barely even understand how it works. Many organizations who have access to directly edit their forward zones don't have that kind of access to their reverse zones and find updating that information to be somewhat of an arcane process.

DNS should really be taught in schools.

18

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.

Most legit senders don't want to look like a compromised box in
someone's bedroom anyway.

19

Jed Smith wrote:

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.

It's a common belief among network operators that if a "server operator" doesn't have access/ability to modify the PTR record for a server, it's a good sign that the server shouldn't be used to send email, but instead should send email thru an email server provided by their upstream access provider.

The people who manage those servers, who can't or won't fix the PTR *or* send email thru an email server provided by their access provider, think it is critically important that the rest of the internet receive their missives. They are mistaken. Their missives come from "a bad neighborhood" (IPs with PTR formats that are strongly associated with botnets) where the odds of any email being desired by the recipient are extremely low. If they want their email to avoid being treated as spam then they need to move to a better neighborhood (fix the PTR) or send from a server located in a better neighborhood (a server with a correct PTR for a mail server).

Endlessly whining "I wanna, I wanna, I can't, You should, I wanna" over and over isn't going to change anything. Other networks aren't going to change how they filter based on PTR for someone who can't properly assign the PTR for their mail server.

jc

20

Blocking based on PTR alone is dangerous, is what I'm saying. I know default
deny is important, but the decision can only be minorly influenced by PTR, not
entirely made on it. There needs to be a better way, but there isn't.

JS