You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Luis Hernán Otegui <lu...@gmail.com> on 2007/04/25 16:04:18 UTC
RBL tests on MTA vs. RBL rules on SA
Hi, list, I know this is one of those "egg and chicken" kind of questions,
but having now the possibility of checking the impact of various setups, I
was wondering if it is more convenient to let the MTA perform the RBL
checks, or disable them and let SA do this job.
Currently I am using zen.spamhaus.org as my primary (and only) RBL tester on
Postfix, and I am kinda surprised. The daily statistics show that my server
is rejecting almost 22000 connections a day, and accepting only 2500-3000
emails. The major drawback is bayes. It seems to lack the necessary amount
of data to catch up as the spam evolves, so I'm continuously getting new
kinds of spam (meaning that I can't figure out a tendency to draw a rule
from).
So I'm asking if anyone has a solution for this, or how do you deal with
this (to me) dellicate balance.
Thanks in advance,
Luis
--
-------------------------------------------------
GNU-GPL: "May The Source Be With You...
-------------------------------------------------
Re: RBL tests on MTA vs. RBL rules on SA
Posted by Randy Smith <pe...@falconsroost.alamosa.co.us>.
Luis Hernán Otegui wrote:
> Well, I have a caching dns running, and it performs (almost) flawlessly.
> zen.spamhaus.org <http://zen.spamhaus.org> seems to perform very well
> here, since when I look at the mail logs I don' find any false
> positives. I was using cbl.abuseat.org <http://cbl.abuseat.org>, bu it
> was too loosy on checks, so many .edu.ar servers from here (I live and
> work here in Argenina) go blacklisted. The point is that ONLY with
> zen.spamhaus.org <http://zen.spamhaus.org> I get this much rejections at
> MTA level. As I said, I'm concerned about if SA geting enough data as it
> needs to get Bayes working as it was a month ago.
I use zen and list.dsbl.org to block outright. We're in the process of
rolling out policyd-weight with postfix so that we can use a couple of
the stricter RBLs (such as the cbl and sorbs) and other tests without as
much fear of the false positives those lists tend to generate.
If your MTA supports it, you might be able to deliver the messages that
would have been rejected by the RBL to a spam box and train off those
messages. Your users never see the messages so they're happy and you can
train SA on them so you're happy.
>
> Regarding sa-update, which channels are you using? I'm currently running
> on saupdates.openproect.com <http://saupdates.openproect.com>. Any
> suggestions on this subject?
updates.spamassassin.org
70_sare_evilnum0.cf.sare.sa-update.dostech.net
70_sare_header0.cf.sare.sa-update.dostech.net
70_sare_header1.cf.sare.sa-update.dostech.net
70_sare_specific.cf.sare.sa-update.dostech.net
72_sare_bml_post25x.cf.sare.sa-update.dostech.net
70_sare_unsub.cf.sare.sa-update.dostech.net
70_sare_stocks.cf.sare.sa-update.dostech.net
I used to use a bunch of others but they hit so rarely that it wasn't
worth keeping them around.
>
>
> Thanks,
>
>
> Luis
>
> 2007/4/25, Randy Smith <perlstalker@falconsroost.alamosa.co.us
> <ma...@falconsroost.alamosa.co.us>>:
>
> Luis Hernán Otegui wrote:
> > Hi, list, I know this is one of those "egg and chicken" kind of
> > questions, but having now the possibility of checking the impact of
> > various setups, I was wondering if it is more convenient to let
> the MTA
> > perform the RBL checks, or disable them and let SA do this job.
> > Currently I am using zen.spamhaus.org <http://zen.spamhaus.org>
> <http://zen.spamhaus.org > as my
> > primary (and only) RBL tester on Postfix, and I am kinda
> surprised. The
> > daily statistics show that my server is rejecting almost 22000
> > connections a day, and accepting only 2500-3000 emails. The major
> > drawback is bayes. It seems to lack the necessary amount of data to
> > catch up as the spam evolves, so I'm continuously getting new kinds of
> > spam (meaning that I can't figure out a tendency to draw a rule
> from).
> > So I'm asking if anyone has a solution for this, or how do you
> deal with
> > this (to me) dellicate balance.
> >
> > Thanks in advance,
> >
>
> I try to block as much as I can before the messages ever hit SA using
> RBLs, HELO checks, greylisting, etc. for performance reasons. SA is a
> much more expensive check so I try not to run it more than necessary.
>
> I don't rely on Bayes here (my users can turn it on or off as they
> choose) but many of the default SA and SARE rulesets pick up changes in
> spam fairly quickly so new spam forms get detected soon enough. (/me
> hugs sa-update)
>
> If you still want to train on the RBL'd messages, you could configure
> your MTA to either feed the messages to sa-learn directly or deliver to
> a mailbox for later training.
>
> --
> Randy Smith
> http://perlstalker.amigo.net/
> "Work is the miracle by which talent is brought to the surface and
> dreams become reality." - Gordon B. Hinckley
>
>
>
>
>
> --
> -------------------------------------------------
> GNU-GPL: "May The Source Be With You...
> -------------------------------------------------
--
Randy Smith
http://perlstalker.amigo.net/
"Work is the miracle by which talent is brought to the surface and
dreams become reality." - Gordon B. Hinckley
Re: RBL tests on MTA vs. RBL rules on SA
Posted by mouss <mo...@netoyen.net>.
Luis Hernán Otegui wrote:
> Well, I have a caching dns running, and it performs (almost) flawlessly.
> zen.spamhaus.org seems to perform very well here, since when I look at
> the
> mail logs I don' find any false positives. I was using
> cbl.abuseat.org, bu
> it was too loosy on checks, so many .edu.ar servers from here (I live and
> work here in Argenina) go blacklisted.
hmmm'. cbl is included in zen... (except for the synchronization delay).
> The point is that ONLY with
> zen.spamhaus.org I get this much rejections at MTA level. As I said, I'm
> concerned about if SA geting enough data as it needs to get Bayes
> working as
> it was a month ago.
Bayes should filter the mail it receives, not the mail it would have
received if this and that...
do you feed errors back to sa-learn?
>
> Regarding sa-update, which channels are you using? I'm currently
> running on
> saupdates.openproect.com. Any suggestions on this subject?
RE: which sa-update channels (was RBL tests on MTA vs. RBL rules on SA)
Posted by Bret Miller <br...@wcg.org>.
<snip>
>
> Regarding sa-update, which channels are you using? I'm
> currently running on saupdates.openproect.com. Any
> suggestions on this subject?
I Use:
updates.spamassassin.org
00_FVGT_File001.cf.sare.sa-update.dostech.net
99_FVGT_meta.cf.sare.sa-update.dostech.net
99_FVGT_Tripwire.cf.sare.sa-update.dostech.net
70_sare_adult.cf.sare.sa-update.dostech.net
70_sare_bayes_poison_nxm.cf.sare.sa-update.dostech.net
70_sare_evilnum0.cf.sare.sa-update.dostech.net
70_sare_evilnum1.cf.sare.sa-update.dostech.net
70_sare_evilnum2.cf.sare.sa-update.dostech.net
70_sare_genlsubj.cf.sare.sa-update.dostech.net
70_sare_header.cf.sare.sa-update.dostech.net
70_sare_highrisk.cf.sare.sa-update.dostech.net
70_sare_html.cf.sare.sa-update.dostech.net
70_sare_obfu0.cf.sare.sa-update.dostech.net
70_sare_oem.cf.sare.sa-update.dostech.net
70_sare_random.cf.sare.sa-update.dostech.net
70_sare_specific.cf.sare.sa-update.dostech.net
70_sare_spoof.cf.sare.sa-update.dostech.net
70_sare_stocks.cf.sare.sa-update.dostech.net
70_sare_unsub.cf.sare.sa-update.dostech.net
70_sare_uri.cf.sare.sa-update.dostech.net
70_sare_uri_eng.cf.sare.sa-update.dostech.net
70_sare_whitelist_rcvd.cf.sare.sa-update.dostech.net
70_sare_whitelist_spf.cf.sare.sa-update.dostech.net
72_sare_bml_post25x.cf.sare.sa-update.dostech.net
72_sare_redirect_post3.0.0.cf.sare.sa-update.dostech.net
99_sare_fraud_post25x.cf.sare.sa-update.dostech.net
70_zmi_german.cf.zmi.sa-update.dostech.net
Some of these are rather aggressive, but we have very, very few false
positives here. And when we do, we simply whitelist the sender so it
doesn't happen again.
Bret
Re: RBL tests on MTA vs. RBL rules on SA
Posted by Luis Hernán Otegui <lu...@gmail.com>.
Well, I have a caching dns running, and it performs (almost) flawlessly.
zen.spamhaus.org seems to perform very well here, since when I look at the
mail logs I don' find any false positives. I was using cbl.abuseat.org, bu
it was too loosy on checks, so many .edu.ar servers from here (I live and
work here in Argenina) go blacklisted. The point is that ONLY with
zen.spamhaus.org I get this much rejections at MTA level. As I said, I'm
concerned about if SA geting enough data as it needs to get Bayes working as
it was a month ago.
Regarding sa-update, which channels are you using? I'm currently running on
saupdates.openproect.com. Any suggestions on this subject?
Thanks,
Luis
2007/4/25, Randy Smith <pe...@falconsroost.alamosa.co.us>:
>
> Luis Hernán Otegui wrote:
> > Hi, list, I know this is one of those "egg and chicken" kind of
> > questions, but having now the possibility of checking the impact of
> > various setups, I was wondering if it is more convenient to let the MTA
> > perform the RBL checks, or disable them and let SA do this job.
> > Currently I am using zen.spamhaus.org <http://zen.spamhaus.org> as my
> > primary (and only) RBL tester on Postfix, and I am kinda surprised. The
> > daily statistics show that my server is rejecting almost 22000
> > connections a day, and accepting only 2500-3000 emails. The major
> > drawback is bayes. It seems to lack the necessary amount of data to
> > catch up as the spam evolves, so I'm continuously getting new kinds of
> > spam (meaning that I can't figure out a tendency to draw a rule from).
> > So I'm asking if anyone has a solution for this, or how do you deal with
> > this (to me) dellicate balance.
> >
> > Thanks in advance,
> >
>
> I try to block as much as I can before the messages ever hit SA using
> RBLs, HELO checks, greylisting, etc. for performance reasons. SA is a
> much more expensive check so I try not to run it more than necessary.
>
> I don't rely on Bayes here (my users can turn it on or off as they
> choose) but many of the default SA and SARE rulesets pick up changes in
> spam fairly quickly so new spam forms get detected soon enough. (/me
> hugs sa-update)
>
> If you still want to train on the RBL'd messages, you could configure
> your MTA to either feed the messages to sa-learn directly or deliver to
> a mailbox for later training.
>
> --
> Randy Smith
> http://perlstalker.amigo.net/
> "Work is the miracle by which talent is brought to the surface and
> dreams become reality." - Gordon B. Hinckley
>
>
>
--
-------------------------------------------------
GNU-GPL: "May The Source Be With You...
-------------------------------------------------
Re: RBL tests on MTA vs. RBL rules on SA
Posted by Randy Smith <pe...@falconsroost.alamosa.co.us>.
Luis Hernán Otegui wrote:
> Hi, list, I know this is one of those "egg and chicken" kind of
> questions, but having now the possibility of checking the impact of
> various setups, I was wondering if it is more convenient to let the MTA
> perform the RBL checks, or disable them and let SA do this job.
> Currently I am using zen.spamhaus.org <http://zen.spamhaus.org> as my
> primary (and only) RBL tester on Postfix, and I am kinda surprised. The
> daily statistics show that my server is rejecting almost 22000
> connections a day, and accepting only 2500-3000 emails. The major
> drawback is bayes. It seems to lack the necessary amount of data to
> catch up as the spam evolves, so I'm continuously getting new kinds of
> spam (meaning that I can't figure out a tendency to draw a rule from).
> So I'm asking if anyone has a solution for this, or how do you deal with
> this (to me) dellicate balance.
>
> Thanks in advance,
>
I try to block as much as I can before the messages ever hit SA using
RBLs, HELO checks, greylisting, etc. for performance reasons. SA is a
much more expensive check so I try not to run it more than necessary.
I don't rely on Bayes here (my users can turn it on or off as they
choose) but many of the default SA and SARE rulesets pick up changes in
spam fairly quickly so new spam forms get detected soon enough. (/me
hugs sa-update)
If you still want to train on the RBL'd messages, you could configure
your MTA to either feed the messages to sa-learn directly or deliver to
a mailbox for later training.
--
Randy Smith
http://perlstalker.amigo.net/
"Work is the miracle by which talent is brought to the surface and
dreams become reality." - Gordon B. Hinckley
Re: RBL tests on MTA vs. RBL rules on SA
Posted by Brian Godette <bg...@idcomm.com>.
Oenus Tech Services wrote:
> After much testing, we have decided to put the RBLs on Postfix for
> performance reasons. Before checking with those RBLs, our system does
> EHLO checks against a known-spammer blacklist database as well to filter
> the most obvious cases. Then we use zen.spamhaus.org,
> safe.dnsbl.sorbs.net, and bl.spamcop.net, in this order. Next we do
safe.dnsbl.sorbs.net includes new.spam.dnsbl.sorbs.net which is not very
safe at all. bl.spamcop.net isn't all that safe either. Both will
routinely hit on the free email providers and major ISPs outgoing MTAs.
This is because both have automatic systems generating them.
Its fairly hard for any sizable ISP or mail provider to not constantly
be going on and off new.spam and spamcop lists given harvested/weak
passwords and the newer bots that will use the MTA configured in the
default mail client of the zombied system including being able to do
SMTP-AUTH.
"safe" sorbs would be something along the lines of:
dul.dnsbl.sorbs.net + relays.dnsbl.sorbs.net + zombie.dnsbl.sorbs.net
Re: RBL tests on MTA vs. RBL rules on SA
Posted by Oenus Tech Services <oe...@oenus.com>.
After much testing, we have decided to put the RBLs on Postfix for
performance reasons. Before checking with those RBLs, our system does
EHLO checks against a known-spammer blacklist database as well to filter
the most obvious cases. Then we use zen.spamhaus.org,
safe.dnsbl.sorbs.net, and bl.spamcop.net, in this order. Next we do
greylisting with postgrey. Then amavisd-new+clamav+sa+sare+fuccyocr take
care of the remaining (our logs show than aprox. 98% of all spam/virus
mail had been blocking before this). We stopped using bayesian at all
since 1.-Many of our customers get their mail through pop3, 2.- those
with imap accounts would not bother training spam and ham. we've had
some (very few) problems in the past with spamassassin giving
false-positives for some ham (though some would say it was spam), but
modifying some scores did the trick without affecting our ability to
filter spam, since most was filtered before it went through
spamassassin. The result: a mail system that hosts more than 100
companies email accounts with no spam at all.
Is there a possibility that we might be blocking sources of legitimate
mail by being so aggressive? My experience tells me that if some server
is on any of the three RBL that we use is because 1.- they're
misconfigured (open relays and such), 2.- they are on a residential
[dynamic] IP segment, 3.- They do permit spam coming from their servers,
4.- if they would be listed by mistake, their IT people are not being
professional enough to have themselves delisted immediately.
Ignasi
Luis Hernán Otegui escribió:
> Hi, list, I know this is one of those "egg and chicken" kind of
> questions, but having now the possibility of checking the impact of
> various setups, I was wondering if it is more convenient to let the MTA
> perform the RBL checks, or disable them and let SA do this job.
> Currently I am using zen.spamhaus.org <http://zen.spamhaus.org> as my
> primary (and only) RBL tester on Postfix, and I am kinda surprised. The
> daily statistics show that my server is rejecting almost 22000
> connections a day, and accepting only 2500-3000 emails. The major
> drawback is bayes. It seems to lack the necessary amount of data to
> catch up as the spam evolves, so I'm continuously getting new kinds of
> spam (meaning that I can't figure out a tendency to draw a rule from).
> So I'm asking if anyone has a solution for this, or how do you deal with
> this (to me) dellicate balance.
>
> Thanks in advance,
>
>
> Luis
>
> --
> -------------------------------------------------
> GNU-GPL: "May The Source Be With You...
> -------------------------------------------------
RE: RBL tests on MTA vs. RBL rules on SA
Posted by Bret Miller <br...@wcg.org>.
> Hi, list, I know this is one of those "egg and chicken" kind
> of questions, but having now the possibility of checking the
> impact of various setups, I was wondering if it is more
> convenient to let the MTA perform the RBL checks, or disable
> them and let SA do this job.
> Currently I am using zen.spamhaus.org as my primary (and
> only) RBL tester on Postfix, and I am kinda surprised. The
> daily statistics show that my server is rejecting almost
> 22000 connections a day, and accepting only 2500-3000 emails.
> The major drawback is bayes. It seems to lack the necessary
> amount of data to catch up as the spam evolves, so I'm
> continuously getting new kinds of spam (meaning that I can't
> figure out a tendency to draw a rule from). So I'm asking if
> anyone has a solution for this, or how do you deal with this
> (to me) dellicate balance.
For me, it's not an either-or choice. The RBLs I can use on the MTA are
very limited because the consequences of a false-positive are very
severe (i.e., the message doesn't even get received). Dropping the same
from SA reduces its effectiveness. So, I just run them in both places.
Repeating a DNS lookup shouldn't be too expensive if your DNS server
caches the result.
Bret