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.


Reply via email to