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/