nor, if using Postfix, postscreen
On 07/01/2014 09:17 PM, Jeremy McSpadden wrote:
No mention of RBLs or greylisting ...
--
Jeremy McSpadden
Flux Labs | http://www.fluxlabs.net<http://www.fluxlabs.net/> | Endless
Solutions
Office : 850-250-5590x501<tel:850-250-5590;501> | Cell :
850-890-2543<tel:850-890-2543> | Fax : 850-254-2955<tel:850-254-2955>
On Jul 1, 2014, at 2:06 PM, "Steve Bergman"
<sbergma...@gmail.com<mailto:sbergma...@gmail.com>> wrote:
Hey motty cruz,
I just moved our 100 users over from our ISP's mail servers to our own.
Apparently, the ISP's mail servers were doing remarkably well. Because it turns
out that we get some 5000 spams a day, and users were getting essentially no
spam.
Then I upgraded us to a new OS on our Debian/X2Go/MATE desktop server, and move
us to our own mail server, and the spam was coming through like water through
the sluice gates of a dam.
It didn't help that I'd moved everyone from Evolution to Thunderbird. So the
client bayesian spam filters were completely untrained.
So I installed SA on the server. That helped. But it wasn't enough. I compiled
up DCC and and installed Pyzor, and that helped some. (Though SA's Pyzor
support had some teething problems, as you can see from my recent posts, which
I think may be now resolved.)
What SA really needs if for its own Bayesian filter to kick in. But to be used
at all, you need at least 200 ham and 200 spam messages registered with it.
i.e. if you have to have a way to train the filter. I don't really have much confidence
in "autolearn". And I'm a little scared of it. So I turned it off. We use
Dovecot. So I used the dovecot-antispam plugin to automatically train SA when mail gets
moved in or out of the junk folder. (It handles the moving of mail from Junk into Trash
or regular folders intelligently and appropriately.)
But that only solved half the problem. You need 200 hams and 200 spams. Mail
was not getting marked as ham when it went into the Inboxes. So I wrote a
script that could be called from the users' .forward files to mark messages as
ham. Then if the user, or Thunderbird's own spam filter chooses to move it to
Junk, it gets relearned as spam.
Finally, to deal with many of the false positives I was getting with SA, I
wrote a script, executed from cron, which takes new mail in the users' Sent
folders, and whitelists them with spamassassin in the users' own individual
user_prefs files.
This is what it took before I was really happy with the performance of SA.
Well... that and adding a 1 second sleep after connection in the Postfix
configuration. That made a huge difference. But our mail volume is small enough
that the 1 second sleep doesn't cause any problems as it would on a really high
volume server.
I hope that rough outline is helpful to you in some way.
However, having come through all that, I find myself wondering if we should
simply impose capital punishment for the crime of spamming, or if more drastic
action is indicated. ;-)
