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.
