You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Sahil Tandon <sa...@hamla.org> on 2004/10/16 19:35:38 UTC

SURBLs not working after upgrade to 3.0

Everything else (i.e. my rules) seem to be working fine.  However, I had 
two problems.

Not so bad: check_mx_attempts and one other variable which now slips my 
mind kept spitting out an 'unable to parse' error.  I don't get that - 
it was EXACTLY the same as with 2.64, with which --lint didn't complain. 
  Are those options now depreciated?

Very bad: SURBLs don't work.  I have the following in local.cf:

loadplugin      Mail::SpamAssassin::Plugin::URIDNSBL

urirhssub URIBL_JP_SURBL  multi.surbl.org.        A   64
header    URIBL_JP_SURBL  eval:check_uridnsbl('URIBL_JP_SURBL')
describe  URIBL_JP_SURBL  Contains a URL listed in JP
tflags    URIBL_JP_SURBL  net

score URIBL_JP_SURBL    4.0

I sent with a test URL:

http://surbl-org-permanent-test-point-MUNGED.com/ (obviously without the 
-MUNGED), and in logs it shows the hit for the email was something like 
0.345.  What gives?

FWIW, I did try other urirhsbl's also as directed by the SURBL web site. 
  Still, same result - or rather, nonresult.

Thanks for your help.

Re: SURBLs not working after upgrade to 3.0

Posted by sa...@hamla.org.
Quoting Sahil Tandon <sa...@hamla.org>:

Problem solved!

> When messages actually arrive from the Internet, Postfix hands off
> messages to amavisd-new+SA which let it through just fine without the
> proper score.  The odd part is that messages that are in the regular
> spamcop relay (not related to SURBL in any way), are scored just fine.

I noticed "AWL" in the test message's headers.  This "test email address" had
been auto whitelisted by SA (the option is apparently activated by default in
amavisd.conf).  Anyway, that's why messages coming from that address were not
being SURBL-scored whereas those in the command line were caught properly.

So the port is fine.  FWIW, for my increased thresholds, the SA defaults for
SUBRL scoring are *not* adequate, which is why I asked about which variables to
modify.  If anyone has this problem in the future, the place to look is
25_uribl.cf.

--
Sahil Tandon

Re: SURBLs not working after upgrade to 3.0

Posted by Sahil Tandon <sa...@hamla.org>.
Jeff Chan wrote:

> Default scores should be ok.  The default configuration should
> have rules and scores already in place.

Firstly, thanks to everyone who has contributed some advice thus far.  I 
ran some spam through spamassassin via the command line.  I su'd to to 
the amavisd-new user (vscan), and spamassassin -D < spammy-message 
clearly shows SA accessing the SURBL lists, and scoring the message 
accordingly.  So it is working, sort of.

When messages actually arrive from the Internet, Postfix hands off 
messages to amavisd-new+SA which let it through just fine without the 
proper score.  The odd part is that messages that are in the regular 
spamcop relay (not related to SURBL in any way), are scored just fine.

Perhaps someone who's familiar with how amavis interfaces with SA could 
lend some advice?  I'll ask some version of this question on that list 
as well.

Thanks.

Re: SURBLs not working after upgrade to 3.0

Posted by Jeff Chan <je...@surbl.org>.
On Sunday, October 17, 2004, 8:04:10 PM, Sahil Tandon wrote:
> Jeff Chan wrote:

>  > That said, it sounds like your installation may be messed up
>  > since init.pre was missing.

> init.pre wasn't missing; the .sample was there since it should be 
> modified to suit the admin's needs and then put in place.  *I* did 
> something wrong; the port/package is fine.

OK.

>> If the default configs, which use urirhssub are not already 
>  > in place as a result of the installation, then that's something
>  > else that may have gone wrong.

> Ah ha!  I think the urirhssub defaults *are* in place because the -D 
> shows use of multi.surbl.org, which was odd to me because I had 
> specified sc.surbl.org (instead of multi) in local.cf.

> So it looks like I now need to know what the appropriate 'score' 
> variable are.  Thanks for the clarification.

Default scores should be ok.  The default configuration should
have rules and scores already in place.

Jeff C.
-- 
Jeff Chan
mailto:jeffc@surbl.org
http://www.surbl.org/


Re: SURBLs not working after upgrade to 3.0

Posted by Loren Wilton <lw...@earthlink.net>.
> So it looks like I now need to know what the appropriate 'score'
> variable are.  Thanks for the clarification.

There are default scores for the 3.0 surbl rules that work fairly well for
most people.

        Loren


Re: SURBLs not working after upgrade to 3.0

Posted by Sahil Tandon <sa...@hamla.org>.
Jeff Chan wrote:

 > That said, it sounds like your installation may be messed up
 > since init.pre was missing.

init.pre wasn't missing; the .sample was there since it should be 
modified to suit the admin's needs and then put in place.  *I* did 
something wrong; the port/package is fine.

> If the default configs, which use urirhssub are not already 
 > in place as a result of the installation, then that's something
 > else that may have gone wrong.

Ah ha!  I think the urirhssub defaults *are* in place because the -D 
shows use of multi.surbl.org, which was odd to me because I had 
specified sc.surbl.org (instead of multi) in local.cf.

So it looks like I now need to know what the appropriate 'score' 
variable are.  Thanks for the clarification.



Re: SURBLs not working after upgrade to 3.0

Posted by Jeff Chan <je...@surbl.org>.
On Sunday, October 17, 2004, 6:28:19 PM, Sahil Tandon wrote:
> And it's probably worth repeating that the default (suggested) local.cf
> entries from www.surbl.org don't tickle spamassassin --lint which exits 
> quietly.

Please don't use the examples in the SURBL Quickstart.  I need
to revise that page to reflect that SA 3.0 ships with default
configs that use urirhssub.  The examples currently show limited
use of urirhsbl, which is deprecated.  urirhssub uses
multi.surbl.org, which is preferred.

That said, it sounds like your installation may be messed up
since init.pre was missing.  If the default configs, which
use urirhssub are not already in place as a result of the
installation, then that's something else that may have gone
wrong.

Jeff C.
-- 
Jeff Chan
mailto:jeffc@surbl.org
http://www.surbl.org/


Re: SURBLs not working after upgrade to 3.0

Posted by Sahil Tandon <sa...@hamla.org>.
Michael Parker wrote:

> init.pre is part of the SA distribution, if your package/port does not
> include it then it is broken and you should complain to your package
> maintainer.  I've forgotten all of the details but init.pre is special
> because it gets loaded before all other files are processed (ie share)
> so that the ifplugin XXXXX lines work correctly in the *.cf files.

It turns out init.pre does not exist, but init.pre.sample *does*.  I 
cp'd that to init.pre, and uncommented the loadplugin line:

loadplugin Mail::SpamAssassin::Plugin::URIDNSBL

And it's probably worth repeating that the default (suggested) local.cf 
entries from www.surbl.org don't tickle spamassassin --lint which exits 
quietly.

I restarted amavisd-new from the appropriate /usr/local/etc/rc.d script 
after putting init.pre in place.  spamassassin -D on a message that had 
been caught by Spamcop URI (w/ 2.64) shows that the plugin is loaded 
just fine; and yet, the URI score never shows up in the spam report.

Boggled.

Re: SURBLs not working after upgrade to 3.0

Posted by Michael Parker <pa...@pobox.com>.
On Sun, Oct 17, 2004 at 03:29:35AM -0400, Sahil Tandon wrote:
> Khalid Waheed wrote:
> 
> >If you are using --siteconfigpath other then default, copy the init.pre 
> >file to location.
> 
> I repeat: there is no init.pre.  The FreeBSD port does not include one, 
> it seems.  Everything else works just dandy via the local.cf and 
> user_prefs files.  I am able to successfully load the plugin via 
> local.cf (when I don't do so, and try to assigns cores, SA complains - 
> i.e. it does work when I load it via local.cf).
> 
> Any other suggestions?
> 

init.pre is part of the SA distribution, if your package/port does not
include it then it is broken and you should complain to your package
maintainer.  I've forgotten all of the details but init.pre is special
because it gets loaded before all other files are processed (ie share)
so that the ifplugin XXXXX lines work correctly in the *.cf files.

So, fix the package/port and your problems may go away.

Michael

Re: SURBLs not working after upgrade to 3.0

Posted by Sahil Tandon <sa...@hamla.org>.
Khalid Waheed wrote:

> If you are using --siteconfigpath other then default, copy the init.pre 
> file to location.

I repeat: there is no init.pre.  The FreeBSD port does not include one, 
it seems.  Everything else works just dandy via the local.cf and 
user_prefs files.  I am able to successfully load the plugin via 
local.cf (when I don't do so, and try to assigns cores, SA complains - 
i.e. it does work when I load it via local.cf).

Any other suggestions?

Re: SURBLs not working after upgrade to 3.0

Posted by Khalid Waheed <kh...@eim.ae>.
If you are using --siteconfigpath other then default, copy the init.pre file to location.




Sahil Tandon wrote:

> Laurent Luyckx wrote:
>
>> Are you sure you're using a recent version of Net::DNS module (>= 0.34)?
>
>
> Indeed.
>
> #pkg_info | grep p5-Net-DNS
> p5-Net-DNS-0.48     Perl5 interface to the DNS resolver, and dynamic 
> updates
>
> I'm still baffled as to why this still doesn't work.
>
> -- 
> Sahil Tandon



Re: SURBLs not working after upgrade to 3.0

Posted by Sahil Tandon <sa...@hamla.org>.
Laurent Luyckx wrote:

> Are you sure you're using a recent version of Net::DNS module (>= 0.34)?

Indeed.

#pkg_info | grep p5-Net-DNS
p5-Net-DNS-0.48     Perl5 interface to the DNS resolver, and dynamic updates

I'm still baffled as to why this still doesn't work.

--
Sahil Tandon

Re: SURBLs not working after upgrade to 3.0

Posted by Laurent Luyckx <la...@luyckx.net>.
On Sat, 2004-10-16 at 19:35, Sahil Tandon wrote:
> Everything else (i.e. my rules) seem to be working fine.  However, I had 
> two problems.
> 
> Not so bad: check_mx_attempts and one other variable which now slips my 
> mind kept spitting out an 'unable to parse' error.  I don't get that - 
> it was EXACTLY the same as with 2.64, with which --lint didn't complain. 
>   Are those options now depreciated?
> 
> Very bad: SURBLs don't work.  I have the following in local.cf:
> 
> loadplugin      Mail::SpamAssassin::Plugin::URIDNSBL
> 
> urirhssub URIBL_JP_SURBL  multi.surbl.org.        A   64
> header    URIBL_JP_SURBL  eval:check_uridnsbl('URIBL_JP_SURBL')
> describe  URIBL_JP_SURBL  Contains a URL listed in JP
> tflags    URIBL_JP_SURBL  net
> 
> score URIBL_JP_SURBL    4.0
> 
> I sent with a test URL:
> 
> http://surbl-org-permanent-test-point-MUNGED.com/ (obviously without the 
> -MUNGED), and in logs it shows the hit for the email was something like 
> 0.345.  What gives?
> 
> FWIW, I did try other urirhsbl's also as directed by the SURBL web site. 
>   Still, same result - or rather, nonresult.

Are you sure you're using a recent version of Net::DNS module (>= 0.34)?

> Thanks for your help.

Cheers

Laurent.


Re: SURBLs not working after upgrade to 3.0

Posted by Theo Van Dinter <fe...@kluge.net>.
On Sat, Oct 16, 2004 at 01:53:21PM -0400, Sahil Tandon wrote:
> This file does not exist on my box.  Without the loadplugin line, --lint 

It should exist in /etc/mail/spamassassin, or wherever your local.cf file
lives.  If not, your installation is incomplete.

> >As usual, run with -D and see what debug says.
> 
> Run what with -D?  spamassassin --lint?  No need - it already exits quietly.

Take your sample message and run it through "spamassassin -D" -- you will see
debug output for the URIBL code if the plugin is loaded (which will also be
shown).

-- 
Randomly Generated Tagline:
"Why is there only one quote?  Because the whiteboard doesn't do syntax
 checking."      - Prof. Finkel

Re: SURBLs not working after upgrade to 3.0

Posted by Mike Burger <mb...@bubbanfriends.org>.
On Sat, 16 Oct 2004, Sahil Tandon wrote:

> Theo Van Dinter wrote:
> 
> >>loadplugin      Mail::SpamAssassin::Plugin::URIDNSBL
> > 
> > this should already be in the default init.pre file.
> 
> This file does not exist on my box.  Without the loadplugin line, --lint 
> spits out errors; with it, it exits quietly.  My machine is FreeBSD 
> 4.10-STABLE and I'm using the latest p5-Mail-Spamassassin package in the 
> ports tree.
> 
> > As usual, run with -D and see what debug says.
> 
> Run what with -D?  spamassassin --lint?  No need - it already exits quietly.

-D indicates debug mode...which will show you exactly what spamassassin is 
doing.
-- 
Mike Burger
http://www.bubbanfriends.org

Visit the Dog Pound II BBS
telnet://dogpound2.citadel.org or http://dogpound2.citadel.org

To be notified of updates to the web site, visit 
http://www.bubbanfriends.org/mailman/listinfo/site-update, or send a 
message to:

site-update-request@bubbanfriends.org

with a message of: 

subscribe

Re: SURBLs not working after upgrade to 3.0

Posted by Sahil Tandon <sa...@hamla.org>.
Theo Van Dinter wrote:

>>loadplugin      Mail::SpamAssassin::Plugin::URIDNSBL
> 
> this should already be in the default init.pre file.

This file does not exist on my box.  Without the loadplugin line, --lint 
spits out errors; with it, it exits quietly.  My machine is FreeBSD 
4.10-STABLE and I'm using the latest p5-Mail-Spamassassin package in the 
ports tree.

> As usual, run with -D and see what debug says.

Run what with -D?  spamassassin --lint?  No need - it already exits quietly.

Re: SURBLs not working after upgrade to 3.0

Posted by Theo Van Dinter <fe...@kluge.net>.
On Sat, Oct 16, 2004 at 01:35:38PM -0400, Sahil Tandon wrote:
> Very bad: SURBLs don't work.  I have the following in local.cf:
> 
> loadplugin      Mail::SpamAssassin::Plugin::URIDNSBL

this should already be in the default init.pre file.

> http://surbl-org-permanent-test-point-MUNGED.com/ (obviously without the 
> -MUNGED), and in logs it shows the hit for the email was something like 
> 0.345.  What gives?

As usual, run with -D and see what debug says.

-- 
Randomly Generated Tagline:
"1) Your kid mistakenly gets sent to the principal's office for asking
 the cafeteria ladies if they macerate."
         - From the Top 12 Signs You've Been Watching Too Much FoodTV