16 Aug
2014
16 Aug
'14
5:17 p.m.
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.
17 Aug
17 Aug
2:13 a.m.
Jason White <jason(a)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
9:49 a.m.
Stewart Smith <stewart(a)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.
2:30 p.m.
Jason White <jason(a)jasonjgw.net> writes:
Stewart Smith <stewart(a)flamingspork.com> wrote:
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
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. 
10:28 a.m.
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
18 Aug
18 Aug
12:46 p.m.
Jason White <jason(a)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.
20 Aug
20 Aug
6:37 p.m.
Trent W. Buck <trentbuck(a)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.
7:49 p.m.
On 20 Aug 2014, at 18:37, Jason White
<jason(a)jasonjgw.net> wrote:
Trent W. Buck <trentbuck(a)gmail.com> wrote:
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
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
21 Aug
21 Aug
10:21 a.m.
Jason White <jason(a)jasonjgw.net> writes:
Trent W. Buck <trentbuck(a)gmail.com> wrote:
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.
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. 
10:30 a.m.
On 21/08/2014 10:21 AM, Trent W. Buck wrote:
Jason White <jason(a)jasonjgw.net> writes:
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.
Trent W. Buck <trentbuck(a)gmail.com> wrote:
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. 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.
2:14 p.m.
Andrew McGlashan
<andrew.mcglashan(a)affinityvision.com.au>
writes:
On 21/08/2014 10:21 AM, Trent W. Buck wrote:
Looks like I only do bigpond and optus, but gmail is included in the
100-ish list of exceptions that upstream already provided.
Jason White <jason(a)jasonjgw.net> writes:
There's a bunch of mail servers that do the same thing. You've got to
whitelist Optus, Gmail and lots more.... Trent W. Buck <trentbuck(a)gmail.com> wrote:
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. 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.
3142
days inactive
3147
days old
10 comments
6 participants
participants (6)
-
Andrew McGlashan -
Chris Samuel -
hannah commodore -
Jason White -
Stewart Smith -
trentbuck＠gmail.com