Re: [SPAM-TAG] Re: SpamCopURI not working
On Thursday, May 12, 2005, 7:02:47 AM, John Stewart wrote: This is killing me here dozens of spams this morning getting through (with bayes, RDJ+SARE, razor, dcc). Without the SpamCopURI working, my detection rate plummets. Any ideas why SpamCopURI would only be querying multi.surbl.org even though all of them are configured in my spamcop_uri.cf? I'm using SA 2.6.4, but with a somewhat old version of perl... other than that, everything is pretty up to date. Tried the latest Net::DNS, but no change. thanks!! johnS Please see my previous response. multi is the only list that should be checked. Jeff C. -- Jeff Chan mailto:[EMAIL PROTECTED] http://www.surbl.org/
RE: [SPAM-TAG] RE: SpamCopURI not working, was RE: More Messed Up www URLs
Your configuration and installation are fine. multi.surbl.org is the only list that should be checked, as it's the combined list with all other SURBL lists included: http://www.surbl.org/lists.html#multi Aha! I think I've found the problem. The behaviour for SpamCopURI must have changed between 0.14 and 0.25. I suspect that with the new version, it moved to using the multi server instead of querying them individually. It's a very cool DNS hack... however, it appears to be a problem with our forwarding nameserver. We've got a firewall box which also is our external DNS server, and forwarding nameserver for our internal boxes (of which our SA box is one). So, when querying achat-montre-rolex.net.ob.surbl.org, it gets 127.0.0.2 just fine. However, when querying achat-montre-rolex.net.multi.surbl.org, the firewall appears to decide that the answer is within a zone it has authority over, and rejects it (returning NXDOMAIN to the internal DNS servers). I'm going to look into figuring out how to allow these queries through properly; I'm sure that's the problem. thank you! johnS
RE: [SPAM-TAG] RE: SpamCopURI not working, was RE: More Messed Up www URLs
However, when querying achat-montre-rolex.net.multi.surbl.org, the firewall appears to decide that the answer is within a zone it has authority over, and rejects it (returning NXDOMAIN to the internal DNS servers). I'm going to look into figuring out how to allow these queries through properly; I'm sure that's the problem. FYI, this was it. Our firewall (a Symantec/Raptor box) is also our DNS forwarder for internal domains. It thought it was authoritative for all 127.0.0.X data, and was returning NXDOMAIN for anything in the 127.0.0.X range (other than 127.0.0.2, curiously). A small config change on the DNS daemon on that box changed it so that it thinks it is only authoritative for 127.0.0.1. All is well, and the surbl.org servers are hitting like crazy now! thanks! johnS
Re: [SPAM-TAG] RE: SpamCopURI not working, was RE: More Messed Up www URLs
On Tuesday, May 10, 2005, 9:32:45 AM, John Stewart wrote: SA lints fine... running it in debug mode, it appears to not be checking anything but the multi records. See below. I've grepped through /usr/share/spamassassin and /etc/mail/spamassasin, and the only URI_RBL reference I find in any .cf file is in /etc/mail/spamassasin/spamcop_uri.cf, which is the config file included with SpamCopURI-0.25 (which has rules and scores for 7 different _URI_RBL's). The only one I'm seeing *ever* hit in my logfiles is SPAMCOP_URL_RBL. This is really killing my spam scanning performance...! [...] debug: using /usr/share/spamassassin for default rules dir debug: using /etc/mail/spamassassin for site rules dir debug: using /var/amavis/.spamassassin for user state dir debug: using /var/amavis/.spamassassin/user_prefs for user prefs file [...] debug: Razor2 results: spam? 0 highest cf score: 0 debug: running raw-body-text per-line regexp tests; score so far=0 debug: running uri tests; score so far=0 debug: uri tests: Done uriRE debug: checking url: http://www.achat-montre-rolex.net./ debug: querying for achat-montre-rolex.net.multi.surbl.org debug: Query failed for achat-montre-rolex.net.multi.surbl.org debug: Receieved match prefix: 127.0.0 debug: Receieved mask: 2 debug: no match debug: checking url: http://www.achat-montre-rolex.net./ debug: returning cached data : achat-montre-rolex.net.multi.surbl.org - ARRAY(0x9b20414) debug: Receieved match prefix: 127.0.0 debug: Receieved mask: 4 debug: no match [...] Your configuration and installation are fine. multi.surbl.org is the only list that should be checked, as it's the combined list with all other SURBL lists included: http://www.surbl.org/lists.html#multi It looks like the issue is that SpamCopURI is getting fooled by the trailing dot in the URI, like the : and other characters that formerly confused SA 3.0 too. Let's ask Eric Kolve to please update SpamCopURI to ignore these extra characters that appear at the end of the host portion of URIs, like SA 3.1 now does, as a result of this bug fix: http://bugzilla.spamassassin.org/show_bug.cgi?id=4191 Jeff C. -- Jeff Chan mailto:[EMAIL PROTECTED] http://www.surbl.org/
