Anti-spam tool preferences?
What would others recommend these days as an anti-spam tool, suitable for integrating into a Postfix/Dovecot configuration? My experience: Spamassassin - when last I used it, accuracy wasn't adequate (at least for classifying my mail) and it tended to be memory-intensive if Bayesian filtering was enabled. Dspam - very good, but I haven't used it for over a decade and it was recently removed from Debian (which wouldn't prevent me from installing it). It doesn't seem to be under ongoing development. CRM114 - not under significant development currently, but it's my solution at the moment and it's giving good accuracy. I haven't tried any others. Nor have I used Dspam or SpamAssassin for a long time now. Up-to-date suggestions are welcome. I have friends who are also considering this issue and thinking about Dovecot Antispam.
Jason White <jason@jasonjgw.net> writes:
Spamassassin - when last I used it, accuracy wasn't adequate (at least for classifying my mail) and it tended to be memory-intensive if Bayesian filtering was enabled.
I use SA, with spamd and memory usage isn't as much of a problem as it was 10 years ago or something. It turns out I have (at least) an order of magnitude more RAM in boxes running SA now. I find it fairly accurate. I also fed it large amounts of spam/ham to train it... and I honestly never look in what it classifies as spam. -- Stewart Smith
Stewart Smith <stewart@flamingspork.com> wrote:
I use SA, with spamd and memory usage isn't as much of a problem as it was 10 years ago or something. It turns out I have (at least) an order of magnitude more RAM in boxes running SA now.
Indeed. I also read somewhere that you should limit the number of child processes it creates if memory constraints are of concern.
Jason White <jason@jasonjgw.net> writes:
Stewart Smith <stewart@flamingspork.com> wrote:
I use SA, with spamd and memory usage isn't as much of a problem as it was 10 years ago or something. It turns out I have (at least) an order of magnitude more RAM in boxes running SA now.
Indeed. I also read somewhere that you should limit the number of child processes it creates if memory constraints are of concern.
Yeah, that used to be an issue too. More so on dialup (email in batches). I think the default now is 5 or something else that's really under what a modern system can handle. -- Stewart Smith
On Sat, 16 Aug 2014 05:17:03 PM Jason White wrote:
Spamassassin - when last I used it, accuracy wasn't adequate (at least for classifying my mail) and it tended to be memory-intensive if Bayesian filtering was enabled.
I'm using Maia Mailguard at home which is a fork of amavisd-new with a web interface that lets me go and look as what's got classified as what and save any false-positives from the spam quarantine (as well as reporting false- negatives). http://www.maiamailguard.com/maia/wiki It's using SpamAssassin and ClamAV for checks and I find it works pretty well for me, I'm happy with that setup. It's not had updates for a while as the maintainer was ill, but the author has said on the mailing list he intends to relicense the stuff he's written under the GPL for a 1.0.4 release (the current codebase is still redistributable, but under certain conditions). cheers, Chris -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC
Jason White <jason@jasonjgw.net> writes:
What would others recommend these days as an anti-spam tool, suitable for integrating into a Postfix/Dovecot configuration?
My experience: Spamassassin Dspam CRM114
These are all post-DATA. You should be rejecting as much as possible BEFORE then, using postscreen, a null MX, a tarpit MX, and so on. Here post-DATA filtering is opt-in, because only managers need it. They get crm114 which is pretty ordinary because our dovecot1 and their mutt MUA don't support the hooks to recognize "I'm moving the mail into Spam folder", so instead there's a nightly cron job that looks for mail with an mtime of "a couple of days ago" and processes that. It's pretty ugly, but they seem to be very happy with the results.
On 20 Aug 2014, at 18:37, Jason White <jason@jasonjgw.net> wrote:
Trent W. Buck <trentbuck@gmail.com> wrote:
These are all post-DATA. You should be rejecting as much as possible BEFORE then, using postscreen, a null MX, a tarpit MX, and so on.
I agree that this is preferable. I've also heard positive comments about grey-listing
full grey listing cab be a pain to use and debug. I've found that sleep 45 && reject unauth_pipelining to achieve much the same with less overhead. this ofc applies to postfix only, apply as necessary
Jason White <jason@jasonjgw.net> writes:
Trent W. Buck <trentbuck@gmail.com> wrote:
These are all post-DATA. You should be rejecting as much as possible BEFORE then, using postscreen, a null MX, a tarpit MX, and so on.
I agree that this is preferable. I've also heard positive comments about grey-listing.
I currently use greylisting for 1s because my postfix version predates postscreen :-( The good folk of #postfix on Freenode told me (IIRC) that postscreen should obviate the need for greylisting. We have to turn greylisting off for Telstra because they have a mail farm, and when postgrey says "try again later", they try from a different node in the farm and so get told "try again later" again. We also do some SPF, but that's pretty boring.
On 21/08/2014 10:21 AM, Trent W. Buck wrote:
Jason White <jason@jasonjgw.net> writes:
Trent W. Buck <trentbuck@gmail.com> wrote:
These are all post-DATA. You should be rejecting as much as possible BEFORE then, using postscreen, a null MX, a tarpit MX, and so on.
I agree that this is preferable. I've also heard positive comments about grey-listing.
I currently use greylisting for 1s because my postfix version predates postscreen :-( The good folk of #postfix on Freenode told me (IIRC) that postscreen should obviate the need for greylisting.
We have to turn greylisting off for Telstra because they have a mail farm, and when postgrey says "try again later", they try from a different node in the farm and so get told "try again later" again.
There's a bunch of mail servers that do the same thing. You've got to whitelist Optus, Gmail and lots more.... I also use greylisting. Cheers A.
Andrew McGlashan <andrew.mcglashan@affinityvision.com.au> writes:
On 21/08/2014 10:21 AM, Trent W. Buck wrote:
Jason White <jason@jasonjgw.net> writes:
Trent W. Buck <trentbuck@gmail.com> wrote:
These are all post-DATA. You should be rejecting as much as possible BEFORE then, using postscreen, a null MX, a tarpit MX, and so on.
I agree that this is preferable. I've also heard positive comments about grey-listing.
I currently use greylisting for 1s because my postfix version predates postscreen :-( The good folk of #postfix on Freenode told me (IIRC) that postscreen should obviate the need for greylisting.
We have to turn greylisting off for Telstra because they have a mail farm, and when postgrey says "try again later", they try from a different node in the farm and so get told "try again later" again.
There's a bunch of mail servers that do the same thing. You've got to whitelist Optus, Gmail and lots more....
Looks like I only do bigpond and optus, but gmail is included in the 100-ish list of exceptions that upstream already provided.
participants (6)
-
Andrew McGlashan -
Chris Samuel -
hannah commodore -
Jason White -
Stewart Smith -
trentbuck＠gmail.com