SORBS on autopilot?

Fri Jan 15 16:17:20 UTC 2010

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