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 <[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>>: > > 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
