[91711] in North American Network Operators' Group
Re: SORBS Contact
daemon@ATHENA.MIT.EDU (Peter Corlett)
Thu Aug 10 05:05:26 2006
In-Reply-To: <44DA6A68.7020209@sorbs.net>
From: Peter Corlett <abuse@cabal.org.uk>
Date: Thu, 10 Aug 2006 10:04:48 +0100
To: NANOG <nanog@merit.edu>
X-SA-Exim-Rcpt-To: nanog@merit.edu, abuse@cabal.org.uk
X-SA-Exim-Mail-From: abuse@cabal.org.uk
Errors-To: owner-nanog@merit.edu
On 10 Aug 2006, at 00:06, Matthew Sullivan wrote:
> [...] This is also why I took the time to create:
>
> http://www.ietf.org/internet-drafts/draft-msullivan-dnsop-generic-
> naming-schemes-00.txt
Why is this information being encoded into the regular PTR records
that already have another purpose, thus reducing its usefulness? It
seems the only purpose is as a bandaid over dumb SORBS policy.
Create a new SPF-like record if you want *additional* information in
DNS. Don't clobber an existing service.
> There are things in the works that will enable the most complained
> about aspects of SORBS to be fixed and to go away permanently...
> The only thing that is delaying it is developer time... So I will
> say this publicly - those that want to see drastic changes @ SORBS
> that are, or have access to a perl coder with SQL knowledge, and is
> able to spend 20-40 hours of pure coding time writing a user
> interface for user permissions & roles in Perl contact me off list
> as the user interface is the only thing that is holding up moving
> to the beta stage of the SORBS2 database.
I have the skills and time, but zero inclination to support SORBS. In
fact, I think I'll hack my mostly-default SpamAssassin configuration
to ignore SORBS. Grepping mailboxes for the SA tag suggests that
SORBS makes no difference in detecting spam, and it tags a number of
legitimate correspondents, including, it appears, Spamcop at
204.15.82.27. (I'm going by the tags SA added to the message since I
can't get past the CAPTCHA on your website to query that address.)
Blacklisting competitors is a low and dirty trick.
