You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Christopher Jett <ch...@jettfuel.net> on 2004/09/28 07:22:16 UTC
SURBL in 3.0
Just upgraded to 3.0 from 2.6.3. I don't see where SURBL is ever
registering a score, where previously it was scoring tons of mail. How
can I verify that it is actually working? I installed it using MCPAN
and --lint shows everything A-OK.
--
Chris Jett
chris@jettfuel.net
Re: SURBL in 3.0
Posted by Jeff Chan <je...@surbl.org>.
On Wednesday, September 29, 2004, 4:58:21 PM, Christopher Jett wrote:
> Still not seeing any hits from SURBL. I do see hits from other RBL's.
[...]
> Tons of spam like this, but no SURBL hits at all. I just verified that
> my Net::DNS is up to date as well. I am at a loss to figure out why
> this is not working. Everything seems in order, but it is stubbornly
> not giving me any SURBL scores.
Can you resolve the SURBL domains from the server you're running
SpamAssassin on:
dig test.surbl.org.multi.surbl.org
What happens when you send yourself a test message with one of
the SURBL test points in it:
http://www.surbl.org/faq.html#test-uris
> SURBL test URLs are:
>
> http://surbl-org-permanent-test-point-MUNGED.com/
>
> or:
>
> http://127.0.0.2-MUNGED/
>
> without the "-MUNGED"s.
Jeff C.
--
Jeff Chan
mailto:jeffc@surbl.org
http://www.surbl.org/
Re: SURBL in 3.0
Posted by Christopher Jett <ch...@jettfuel.net>.
I forgot to mention that the only thing unusual about my local.cf file
is that it rewrites the Subject header differently than the standard
installed local.cf file. This same problem is also repeatable with
either spamassassin, or spamc/spamd when using the --siteconfigpath
directive.
--
Chris Jett
chris@jettfuel.net
On Sep 29, 2004, at 10:57 PM, Christopher Jett wrote:
> OK - I think I have narrowed down what is happening with this, though
> I don't know why. I have placed my local.cf file in a non-standard
> directory and I am using the --siteconfigpath=path to point to that
> directory (where my local.cf file and my own custom rules files are
> located). For some reason this breaks the SURBL checks. If I run
> spamassassin without that directive (and use local.cf in its standard
> installation location), the SURBL checks work fine. Can someone else
> confirm this? This is with 3.0.0.
> --
> Chris Jett
> chris@jettfuel.net
>
Re: SURBL in 3.0
Posted by Theo Van Dinter <fe...@kluge.net>.
On Thu, Sep 30, 2004 at 09:44:20AM -0700, Justin Mason wrote:
> if the init.pre is never read from what you specify as --siteconfigpath,
> that's a bug -- could you report it to the bugzilla? (however I'm
> pretty certain we have a test for that so that sounds odd.)
I think the issue is that init.pre isn't in the directory he's pointing to,
not that it wouldn't be read if it existed there. ie:
spamassassin --siteconfigpath /tmp/foo
if I don't put init.pre in /tmp/foo, spamassassin isn't going to go looking
for the file in other places.
--
Randomly Generated Tagline:
"Remember: The difference between something that might go wrong and
something that can't possibly go wrong is that something that can't
possibly go wrong is impossible to fix." - Peter Sagerson
Re: SURBL in 3.0
Posted by Doug Brott <br...@redh.com>.
Theo Van Dinter wrote:
>On Thu, Sep 30, 2004 at 01:42:51PM +0200, Maurice Lucas wrote:
>
>
>>>OK - I think I have narrowed down what is happening with this, though I
>>>don't know why. I have placed my local.cf file in a non-standard
>>>directory and I am using the --siteconfigpath=path to point to that
>>>directory (where my local.cf file and my own custom rules files are
>>>located). For some reason this breaks the SURBL checks. If I run
>>>spamassassin without that directive (and use local.cf in its standard
>>>installation location), the SURBL checks work fine. Can someone else
>>>confirm this? This is with 3.0.0.
>>>
>>>
>
>The problem, I'm guessing, is that the init.pre file (loads the plugins)
>installs into the standard siteconfigpath directory. So if you aim
>somewhere else, the plugins are never enabled, so no SURBL.
>
>
>
I had a problem a couple of months back .. probably should have
submitted a but report, but I didn't take the time to narrow it down. I
had two installations that were virtually identicle running. One ran
SURBL both easily and as expected. The other, seemed to be working but
never generated any results in the SA report log. The working system
was Fedora Core 2 and the apparently non-working system was Fedora Core
1. After upgrading from the Stock Perl installation with Fedora Core 1
to the up2date release in Fedora Core 2, SpamAssassin started working as
expected.
I guess that I pawned it off as not properly reading the release notes,
yada yada yada. But, I the bottom line is that for SURBL to work
properly, there seems to be a minimum release of Perl that is
necessary. A stock Fedora Core 2 works right, but a stock Fedora Core 1
doesn't (at least in my case).
Oh, and thanks guys (Theo, Justin, others) these tools are the bomb.
You've made reading e-mail fun again :)
--
Doug Brott
Re: SURBL in 3.0
Posted by Theo Van Dinter <fe...@kluge.net>.
On Thu, Sep 30, 2004 at 01:42:51PM +0200, Maurice Lucas wrote:
> >OK - I think I have narrowed down what is happening with this, though I
> >don't know why. I have placed my local.cf file in a non-standard
> >directory and I am using the --siteconfigpath=path to point to that
> >directory (where my local.cf file and my own custom rules files are
> >located). For some reason this breaks the SURBL checks. If I run
> >spamassassin without that directive (and use local.cf in its standard
> >installation location), the SURBL checks work fine. Can someone else
> >confirm this? This is with 3.0.0.
The problem, I'm guessing, is that the init.pre file (loads the plugins)
installs into the standard siteconfigpath directory. So if you aim
somewhere else, the plugins are never enabled, so no SURBL.
--
Randomly Generated Tagline:
"As for SUVs being used as family cars: If a family is too large to
fit into a fuel efficient automobile it doesn't need an SUV, it needs
birth control." - Unknown
Re: SURBL in 3.0
Posted by Maurice Lucas <ms...@taos-it.nl>.
> OK - I think I have narrowed down what is happening with this, though I
> don't know why. I have placed my local.cf file in a non-standard
> directory and I am using the --siteconfigpath=path to point to that
> directory (where my local.cf file and my own custom rules files are
> located). For some reason this breaks the SURBL checks. If I run
> spamassassin without that directive (and use local.cf in its standard
> installation location), the SURBL checks work fine. Can someone else
> confirm this? This is with 3.0.0.
So that's the reason why I don't see any SURBL checks in the headers
(_TESTSSCORES_)
I do see "uri tests; score so far=-2.599" in my debug logfile but never any
line like:
2.0 URIBL_WS_SURBL Contains a URL listed in sa-blacklist
[URIs: ca-t.com]
I didn't change anything to Makefile.PL, so it's a simple install with
a --siteconfigpath=path for starting spamd
A test message with
http://surbl-org-permanent-test-point-MUNGED.com/
without "-MUNGED"
Give the following result in the debug logfile
uri found: http://surbl-org-permanent-test-point-MUNGED.com/
And in the headers
X-Spam-Status: No, hits=-2.1 required=7.0 tests=ALL_TRUSTED=-3.3,AWL=3.193,
BAYES_20=-1.951 autolearn=ham version=3.0.0
With kind regards,
Met vriendelijke groet,
Maurice Lucas
TAOS-IT
Re: SURBL in 3.0
Posted by Christopher Jett <ch...@jettfuel.net>.
OK - I think I have narrowed down what is happening with this, though I
don't know why. I have placed my local.cf file in a non-standard
directory and I am using the --siteconfigpath=path to point to that
directory (where my local.cf file and my own custom rules files are
located). For some reason this breaks the SURBL checks. If I run
spamassassin without that directive (and use local.cf in its standard
installation location), the SURBL checks work fine. Can someone else
confirm this? This is with 3.0.0.
--
Chris Jett
chris@jettfuel.net
Re: SURBL in 3.0
Posted by Christopher Jett <ch...@jettfuel.net>.
On Sep 28, 2004, at 3:18 AM, John Andersen wrote:
> On Monday 27 September 2004 09:22 pm, Christopher Jett wrote:
>> Just upgraded to 3.0 from 2.6.3. I don't see where SURBL is ever
>> registering a score, where previously it was scoring tons of mail.
>> How
>> can I verify that it is actually working? I installed it using MCPAN
>> and --lint shows everything A-OK.
>> --
>> Chris Jett
>> chris@jettfuel.net
>
> Did you enable it in your local.cf as per the surbl pages?
> I'm not absolutely sure You still have to do that, because I get
> reports from _AB_ and _OS_ even though I have no specific
> content in my local.cf for those.
>
> Check your init.pre to see if these lines appear and are uncommented:
> # URIDNSBL - look up URLs found in the message against several DNS
> # blocklists.
> #
> loadplugin Mail::SpamAssassin::Plugin::URIDNSBL
>
>
>
> You should see things like this:
> 0.4 URIBL_AB_SURBL Contains an URL listed in the AB SURBL
> blocklist
> [URIs: ca-t.com]
> 2.0 URIBL_WS_SURBL Contains a URL listed in sa-blacklist
> [URIs: ca-t.com]
> 3.2 URIBL_OB_SURBL Contains an URL listed in the OB SURBL
> blocklist
> [URIs: ca-t.com]
> 4.0 URIBL_SC_SURBL Contains a URL listed in SpamCop data
> [URIs: ca-t.com]
>
>
> --
> _____________________________________
> John Andersen
Still not seeing any hits from SURBL. I do see hits from other RBL's.
Here's a sample:
* 0.4 HTML_SHORT_LENGTH BODY: HTML is extremely short
* 3.2 DOMAIN_RATIO BODY: Message body mentions many internet domains
* 0.0 HTML_MESSAGE BODY: HTML included in message
* 2.1 BAYES_95 BODY: Bayesian spam probability is 95 to 99%
* [score: 0.9859]
* 0.2 MIME_HTML_ONLY BODY: Message only has text/html MIME parts
* 0.0 HTML_90_100 BODY: Message is 90% to 100% HTML
* 3.3 HTML_IMAGE_ONLY_04 BODY: HTML: images with 0-400 bytes of words
* 2.0 RCVD_IN_SORBS_DUL RBL: SORBS: sent directly from dynamic IP
address
* [81.44.185.240 listed in dnsbl.sorbs.net]
* 0.1 RCVD_IN_NJABL_DUL RBL: NJABL: dialup sender did non-local SMTP
* [81.44.185.240 listed in combined.njabl.org]
* 0.0 HTML_SHORT_CENTER HTML is very short with CENTER tag
* 4.1 RATWARE_ZERO_TZ Bulk email fingerprint (+0000) found
* 0.6 FORGED_OUTLOOK_HTML Outlook can't send HTML message only
* 0.1 FORGED_OUTLOOK_TAGS Outlook can't send HTML in this format
Tons of spam like this, but no SURBL hits at all. I just verified that
my Net::DNS is up to date as well. I am at a loss to figure out why
this is not working. Everything seems in order, but it is stubbornly
not giving me any SURBL scores.
--
Chris Jett
chris@jettfuel.net
Re: SURBL in 3.0
Posted by John Andersen <js...@pen.homeip.net>.
On Monday 27 September 2004 09:22 pm, Christopher Jett wrote:
> Just upgraded to 3.0 from 2.6.3. I don't see where SURBL is ever
> registering a score, where previously it was scoring tons of mail. How
> can I verify that it is actually working? I installed it using MCPAN
> and --lint shows everything A-OK.
> --
> Chris Jett
> chris@jettfuel.net
Did you enable it in your local.cf as per the surbl pages?
I'm not absolutely sure You still have to do that, because I get
reports from _AB_ and _OS_ even though I have no specific
content in my local.cf for those.
Check your init.pre to see if these lines appear and are uncommented:
# URIDNSBL - look up URLs found in the message against several DNS
# blocklists.
#
loadplugin Mail::SpamAssassin::Plugin::URIDNSBL
You should see things like this:
0.4 URIBL_AB_SURBL Contains an URL listed in the AB SURBL blocklist
[URIs: ca-t.com]
2.0 URIBL_WS_SURBL Contains a URL listed in sa-blacklist
[URIs: ca-t.com]
3.2 URIBL_OB_SURBL Contains an URL listed in the OB SURBL blocklist
[URIs: ca-t.com]
4.0 URIBL_SC_SURBL Contains a URL listed in SpamCop data
[URIs: ca-t.com]
--
_____________________________________
John Andersen