On Mon, Jan 11, 2010 at 10:01:11AM -0600, Larry Smith's said:

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 -- Ken Chase - ken@heavycomputing.ca - +1 416 897 6284 - Toronto CANADA Heavy Computing - Clued bandwidth, colocation and managed linux VPS @151 Front St. W.

On Tue, 12 Jan 2010, Jed Smith wrote:

...

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

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?

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. ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________

on Tue, Jan 12, 2010 at 11:51:47AM -0500, Jed Smith wrote:

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

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. -- 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/

On Jan 12, 2010, at 10:31 AM, Jed Smith wrote:

Given the first few replies I received, allow me to clarify, now that I've ... apparently angered the anti-spam crowd:

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. -- bk

On Jan 12, 2010, at 1:09 PM, Rich Kulawiec wrote:

On Tue, Jan 12, 2010 at 10:48:31AM -0800, Brian Keefer wrote:

...

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.

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.

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. -- bk

On Tue, 12 Jan 2010 13:56:01 -0500, JC Dill <jcdill.lists@gmail.com> wrote:

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.

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

On Tue, Jan 12, 2010 at 11:51:47AM -0500, Jed Smith wrote:

On Jan 11, 2010, at 11:11 AM, Jon Lewis wrote: 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. Most legit senders don't want to look like a compromised box in someone's bedroom anyway. -- Dave ----- Nobody believed that I could build a space station here. So I built it anyway. It sank into the vortex. So I built another one. It sank into the vortex. The third station burned down, fell over then sank into the vortex. The fourth station just vanished. And the fifth station, THAT stayed!

On 01/12/2010 10:48 AM, Dave Martin wrote:

On Tue, Jan 12, 2010 at 11:51:47AM -0500, Jed Smith wrote:

...

On Jan 11, 2010, at 11:11 AM, Jon Lewis wrote: 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. Mike

On 01/12/2010 11:34 AM, Patrick W. Gilmore wrote:

On Jan 12, 2010, at 2:11 PM, Michael Thomas wrote:

...

On 01/12/2010 10:48 AM, Dave Martin wrote:

...

On Tue, Jan 12, 2010 at 11:51:47AM -0500, Jed Smith wrote:

...

On Jan 11, 2010, at 11:11 AM, Jon Lewis wrote: 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

on Tue, Jan 12, 2010 at 02:59:55PM -0500, Jed Smith wrote:

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. -- 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/

On Tue, Jan 12, 2010 at 11:11:13AM -0800, Michael Thomas wrote:

...

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.

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

On Tue, 12 Jan 2010 11:27:32 PST, Brian Keefer said:

On Jan 12, 2010, at 10:48 AM, Dave Martin wrote:

listen to the guy in the next cube over say "setup your RDNS" probably half a dozen times a day.

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.. ;)

On Jan 11, 2010, at 11:15 AM, telmnstr@757.org wrote:

...

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

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

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. -- TTFN, patrick

On 1/11/2010 8:54 AM, telmnstr@757.org wrote:

...

Did SORBS really cause you that much pain? SORBS causes people pain every day. I worked at an ISP that used SORBS and it was nothing short of a nightmare. Donations to ge things removed, nobody would help you, everything was 'automated' and if somehow something pissed off the 'automation process' you were subject to things just staying broken.

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.

...

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

telmnstr@757.org wrote: 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...?!?!?

Ronald Cotoni wrote:

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.

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

On Mon, 2010-01-11 at 11:15 -0500, telmnstr@757.org wrote:

...

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

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

"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 :) Gord -- error: wit pool entropy approaching zero. system halted. again.

On Fri, Jan 15, 2010 at 11:06 AM, Michelle Sullivan <matthew@sorbs.net> wrote:

...

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 -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004

On Fri, Jan 15, 2010 at 11:26 AM, William Hamilton <bill@edisys.co.uk> wrote:

...

...

Is it bad English?  Is it not clear? No, it is not clear.

Try as I might I really can't see what is not clear here...

It isn't clear that there's a way to reach a human being at sorbs other than complaining acerbically on a newsgroup or mailing list. Question asked. Question answered. I don't care to debate the matter, so make of it what you wish. Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004

William Hamilton wrote:

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

The difference is that nobody wants to "talk" to a robot when they're the victim of a false positive which is causing business impacting interruption. A robot is not empowered to go beyond its instructions, and if it's programmed either wrong or with inadequate nuance, there is no escalation. Let's not forget that IVR mazes and their modern day counterparts have been built in large part not to resolve problems but to reduce the cost of "support" by expensive human automatons to the point that it's often incidental if they actually solve problems. This is not a well kept secret, and when you're trapped by one especially when it's produced a crisis, its rather disingenuous and maddening for the IVR's keeper to cop attitude. A much better approach -- assuming that the goal is actually to resolve problems rather than shield resources -- is to at least make the escalation process transparent. Knowing what you have to do in order to get ahold of some of something empowered to resolve problems is a lot better than a robot telling you to take the next turn in a twisty maze. Mike, this is hardly SORBS specific lest anybody be confused

William Hamilton wrote:

On 15/01/2010 16:57, Michael Thomas wrote:

...

The difference is that nobody wants to "talk" to a robot when they're the victim of a false positive which is causing business impacting interruption. A robot is not empowered to go beyond its instructions, and if it's programmed either wrong or with inadequate nuance, there is no escalation.

Sure, and that's understandable.

...

Let's not forget that IVR mazes and their modern day counterparts have been built in large part not to resolve problems but to reduce the cost of "support" by expensive human automatons to the point that it's often incidental if they actually solve problems. This is not a well kept secret, and when you're trapped by one especially when it's produced a crisis, its rather disingenuous and maddening for the IVR's keeper to cop attitude.

A much better approach -- assuming that the goal is actually to resolve problems rather than shield resources -- is to at least make the escalation process transparent. Knowing what you have to do in order to get ahold of some of something empowered to resolve problems is a lot better than a robot telling you to take the next turn in a twisty maze.

I agree it's perhaps not clear how to get hold of a human, but you can't really argue that it's not clear how to progress the issue in general as the message quite clearly tells you to respond if you wish for it to be re-opened.

I can't accept that the instructions that the bot provided were unclear, but can organisations in general (again, not SORBS-specific) do better when dealing with their "customers"?

Here's the general problem I have. As "customers", we've gone from the expectation that support was there to support us, to the general presumption that the "customers" are the problem and need to take Turing Tests, and jump through all manner of hoops in order to be deigned worthy of help. That's great if your base motivation is to reduce the bottom line of support costs, but lets not equivocate that the experience isn't on average far, far worse for those on the receiving end of these systems. In this particular case, it isn't whether the instructions aren't clear per se. It's that there isn't any recourse if for whatever reason they are not. Badgering the "customers" who don't understand your process is either cynical or clueless. If your customers don't understand, that's your problem. Always. Assuming that support is there to support, of course. So in general, it's this new age attitude of "you must conform to my cost targets" toward support that sucks. Mike

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 On Fri, Jan 15, 2010 at 05:06:18PM +0100, Michelle Sullivan's said:

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

-- Ken Chase - ken@heavycomputing.ca - +1 416 897 6284 - Toronto CANADA Heavy Computing - Clued bandwidth, colocation and managed linux VPS @151 Front St. W.

paul wrote:

Michelle,

Thanks for your email. Please specifically look at ticket 260695. I created the ticket on January 5th at about 1:30EST. Immediately I got my response from the robot.

See my other message in addition.

I replied a few minutes later with:

...

67.196.137.188/32

TTL is right. PTR is right.

That is my view, however most (if not all) of the tickets were for the /22 not the /32 which is why it was rejected.

From your email, it is my understanding this should have went to a human. I have no idea why my IP address wasn't accepted in the first place. And I have no idea why I didn't get a human response.

So go back to the robot response and tell me where it says it'll be sent to a human...please...?

A couple suggestions: -program the robot to give the exact reason why it is denying: TTL wrong or PTR indicates dynamic or whatever

It does give several responses, however the more exact the response the more issues we have had with people not understanding the reply. Our response has been to format the message with a link to the FAQ where there is a lot more of a detailed response. I will review the response with your suggestions and see if we can change it to some sort of compromise.

-kind of leaping to conclusions here, but possibly the robot is caching DNS? Which means even if what was broken had been fixed, the robot wouldn't see it?

The robot caches results for 48 hours to prevent people launching DoS attacks on our systems as well as yours. The results are easily checked here: http://nemesis.sorbs.net:82/<first octet>/<second octet>/<network>.txt eg: http://nemesis.sorbs.net:82/67/196/67.196.137.0.txt In this case you can easily see why the robot was unable to process the request... PTR's were requested from the nominated authoritive servers, only to receive a "NODATA" response (commonly seen if TCP responses are required or CNAMEs are returned without the PTR.) There is an issue with the robot and some correctly assigned classless delegations due to the way we process the data, there are various catches to correct this and re-process the network with a more reliable (but considerably more resource hungry) method. Unfortunately it's not fool proof though, which is why we tell people to respond to the robot response to get a human to review it. If anyone out there is knowledgable in Perl, C and DNS and wants to take a shot at fixing that issue I'd love to have the help. Michelle

Ken Chase wrote:

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

260573 - waiting for a response from a SORBS admin (originally requested the /22, but really only meant to request a /32) 260695 - is 260573 261026 - waiting for response from the requestor (and is now merged with 260695 as it's the same host) 261204 - waiting for response from the requestor (and is now merged with 260695 as it's the same host) 261325 - waiting for response from the requestor (and is now merged with 260695 as it's the same host) 261377 - had no information about any ticket and was logged to the lowest priority queue, and is actually the same as the above from the same requestor. 261624 - waiting for response from the requestor (and 260573, 260695, 261026, 261204, 261325, 261377 are all merged into it as then are all for the same host.)

and the last ticket I posted was from NAC's admin, who received and acted on replies too.

The NAC admin had not replied to the ticket as I stated previously.

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.

Well 3 people have ignored the last 2 sentences... so please tell me what is unclear in them? The only correct response was in 260573 when someone responded to the robot response. For the onlookers, please note that the SORBS stated reply time has been complied with in all cases, and had the other tickets not been logged for the same issue by the same requestor it would have been answered by today to stay in that response time compliance. Michelle

In a message written on Fri, Jan 15, 2010 at 05:06:18PM +0100, Michelle Sullivan wrote:

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.

So, let me see if I got this right: 1) Network reports 1.2.3.0/24 has no dynamic IP addresses in it. 2) SORBS robot reponds with "you must change your rDNS." 3) Profit? What your telling me is the SORBS list of "dynamic IP's" is in fact not a list of dynamic IP's. Rather it is the "SORBS list of things that have DNS names that look like dynamic IP's". Rather than take on the burden of making the list reflect what you say it does (dynamic IP's) by for instance taking the report and putting it in some sort of exception list (possibly with some investigation) you're putting all the burden back on the network operator. Given that it only operates on DNS names, one has to wonder if there is any value to the list. I can easily put a list of prohibited dns forms in my local blackist (e.g. dhcp-.*) and then I don't have to query the DNSbl, reducing network traffic and latency. It would appear to me SORBS is providing no value (in the specific cause of the dynamic IP list) if this is the case. The entire point of "outsourcing" the list to SORBS would be to get something better than just a regex on DNS names, but that appears to be all that is being provided. -- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/

This will be my only reply to the conversation now that Michelle has poked in and taken control of the thread. I had a beef with SORBS a while back on behalf of my day job, and it cost me quite a bit -- in frustration, in doing a few things publicly that I regret, and ultimately in spending a month of my life fighting with Michelle over a God damned /24 and its erroneous listing. That confrontation haunts me today, and not necessarily because either of us screwed up at any level. We both did, but I'm haunted today because of the bad blood that the confrontation produced. I am not going to revisit that experience, but it did grant something to share. I can only hope that differences aside, Michelle respects my wishes and does not turn NANOG into his/her and my personal fighting ground -- what's in the past is done, and I'm only sharing what I learned from it, not the events that transpired over said /24. I walked away from that experience having learned a number of things. Firstly, I damaged my reputation at my employer as a direct result of getting sucked in to the emotional vortex that dealing with Michelle caused -- something in the callous, biting, confrontational demeanor with which Michelle composes herself brings out the worst in me and summons forth tribal battle rage. The fact that the medium is a keyboard and not a face-to-face conversation does not help. Secondly, I learned about myself and my weaknesses, particularly in dealing with the public. If there's anything a competent network administrator needs to master, it's dismissing a sense of entitlement. SORBS is going to do whatever the hell it wants, and Michelle may or may not work with you on getting SORBS to stop doing what's bugging you. The biggest mistake I made was turning that into a crusade to prove her wrong; I am reminded about the (ever inappropriate) Special Olympics analogy relating to Internet arguing which is strangely appropriate when dealing with Michelle. (As an aside, this second point has drastically altered my dealings with service providers. I yell a /lot/ less when my home Internet connection goes out now, and I'm all that much better for it. I'm really pleased I learned to let go.) Thirdly, and possibly most importantly, I learned a valuable life lesson about dealing with people like Michelle and how much it isn't worth it. SORBS has a particularly vile reputation, and given Michelle's treatment of folks in this thread it is no mystery why. Aside from Ricky's solitary post of January 14th, this thread had mostly moved on from SORBS and addressed other topics -- granted, it was frightfully meta and a candidate for leaving well enough alone. Spam-L moderated Michelle for the exact same fault she is demonstrating here -- even on a mailing list comprised of the who's-who of Internet network administration, she will drag everybody subscribed through torment and misery while attempting to defend supposed SORBS reputation in an ongoing crusade to prove herself right. In Spam-L's case, it was with me; in NANOG's case, it's with a number of people who have spoken negatively re: SORBS. I am not dismissing blame from those fanning the conversation, but merely giving credit where credit is due. Let me reiterate for the benefit of Ricky Beam, Ken Chase, Leo Bicknell, Paul, and anybody else who is tempted to debate Michelle in this thread: you are 100% wasting your time. Your time is much better spent contacting every mail administrator on the Internet who 5xx's your relay's mail, or asking your upstream to move you out of the affected block. Both will result in more productivity than debating anybody that works for SORBS or who is a colleague of Michelle Sullivan. You might be right, she might be right, and in either case it doesn't matter. Move on. There are far more pressing matters in life. Now then, that said... I'm going to humbly request as a subscriber to NANOG that "my ticket wasn't handled to my satisfaction" mails, even in spite of the above advice, remove nanog@nanog.org from the distribution list and become a private matter. If Michelle genuinely cares about cleaning up SORBS and raising its reputation, she will not have a problem with this. If moving to a private conversation is problematic for all involved parties, I hope it moves to another list. JS

On Jan 15, 2010, at 12:08 PM, Michelle Sullivan wrote:

...

2) SORBS robot reponds with "you must change your rDNS."

... or respond to indicate why you think the robot is wrong...

This does not work. Our provider has been told that unless the in-addr was changed to include the word "static", the listing would not be lifted, full stop. And yes, this was after entering tickets & following other procedures. (How do you think we got a human to respond? I don't post these things to mailing lists or newsgroups, just like I am not giving the provider's name or ticket number here.) Personally, I do not mind telling people "you must enter a ticket" or at least try the automated system. If there are ways to have the user help themselves, all the better. But lying (either Michelle in this thread, or the volunteer who responded to us) is not only unproductive, it is downright destructive. I also note that many other DULs have self-removal for nothing more than asking. Bots do not ask. These other DULs are more widely used, some have better metrics (both FPs and blocking rates, probably because providers are willing to work with them), and no one bitches about them in public, as people do about SORBS every week or few. -- TTFN, patrick

Logan Vig wrote:

Here are some tickets to review:

205929

206524

207964

208986

and for the /24's which finally resulted in the /18 being delisted:

208996-209062

Well from the initial look you kept submitting new tickets and the SORBS staff kept merging them into the latest ticket as previously stated. You in effect delayed any human response yourself.... and it looks like you managed to exploit a flaw in the system to bypass the delisting rules as you were not entitled to be delisted at the time. I'd suggest you might want to not push things or I will review the entire entry with a view to correcting any incorrect delisting. No that's not retaliatory, that's just correcting an error that you have just alerted me to... (if however, you are entitled not to be listed now, the entry would not be re-instated..) Michelle

-----Original Message----- From: bmanning@vacation.karoshi.com [mailto:bmanning@vacation.karoshi.com] Sent: Friday, January 15, 2010 1:54 PM To: Michelle Sullivan Cc: nanog@nanog.org Subject: um... human generated requests

If I may ... two questions:

a) do the humans @ SORBS use the AI/GUI that everyone else uses to query/request changes or do all SORBS internal manipulations use an entirely different AI/GUI?

b) is there any method for someone to request their (as opposed to someone elses) prefix be added to SORBS? e.g.

whois 192.0.2.0

Slightly confused - it sounds like you're asking if you can list yourself on a blacklist? Is that a self-immolating form of protest, or did I misread? Best Regards, Nathan Eisenberg

On Fri, Jan 15, 2010 at 02:14:03PM -0800, Nathan Eisenberg wrote:

...

-----Original Message----- From: bmanning@vacation.karoshi.com [mailto:bmanning@vacation.karoshi.com] Sent: Friday, January 15, 2010 1:54 PM To: Michelle Sullivan Cc: nanog@nanog.org Subject: um... human generated requests

If I may ... two questions:

a) do the humans @ SORBS use the AI/GUI that everyone else uses to query/request changes or do all SORBS internal manipulations use an entirely different AI/GUI?

b) is there any method for someone to request their (as opposed to someone elses) prefix be added to SORBS? e.g.

whois 192.0.2.0

Slightly confused - it sounds like you're asking if you can list yourself on a blacklist? Is that a self-immolating form of protest, or did I misread?

Best Regards, Nathan Eisenberg

pegged it in one. to borrow lines from Arlo Guthrie... "And the only reason I'm singing you this song now is cause you may know somebody in a similar situation, or you may be in a similar situation, and if your in a situation like that there's only one thing you can do and that's walk into the shrink wherever you are, just walk in say "Shrink, You can get anything you want, at Alice's restaurant.". And walk out. You know, if one person, just one person does it they may think he's really sick and they won't take him. And if two people, two people do it, in harmony, they may think they're both faggots and they won't take either of them. And three people do it, three, can you imagine, three people walking in singin a bar of Alice's Restaurant and walking out. They may think it's an organization. And can you, can you imagine fifty people a day,I said fifty people a day walking in singin a bar of Alice's Restaurant and walking out. And friends they may thinks it's a movement. And that's what it is , the Alice's Restaurant Anti-Massacre Movement, and all you got to do to join is sing it the next time it come's around on the guitar. With feeling.".... --bill