Getting a new server

[Ted Mittelstaedt]

>-----Original Message-----
>From: owner-freebsd-questions at freebsd.org
>[mailto:owner-freebsd-questions at freebsd.org]On Behalf Of Chad
>Leigh -- Shire.Net LLC
>Sent: Friday, February 03, 2006 11:29 PM
>To: Ted Mittelstaedt
>Cc: freebsd-questions at freebsd.org; Lisa Casey
>Subject: Re: Getting a new server
>
>
>
>On Feb 2, 2006, at 2:37 AM, Ted Mittelstaedt wrote:
>> I would suggest you not use spamassassin.  If you must use content
>> filtering use dspam, as it can be set to allow users to easily feed
>> the learner.  spamassassin cannot.
>
>For IMAP users, spamassassin can EASILY be set up to allow the users
>to feed the system.   It is harder for pop users, I agree.  My users
>don't feed at all as it is too hard to explain to them what to do so
>I just feed all my spam in (including positives to reinforce) and my
>uses don't complain about spamassassin's results so it must be
>working.  I figure that most spam out there is so widespread that
>most of my users spam overlaps the spam I get on my 7 or 8 accounts I
>use.
>

But, dspam makes it so rediculously easy for both POP and IMAP
users to feed the learner that the users have no excuse for not using
it.

spam complaints are all user-driven anyway, and with dspam I can
give them a web interface that a child can use, to feed the learner.
Then I don't have to spend time on it, and if the users don't spend the
few minutes to feed it, then they only have themselves to blame for
the spam in their box.

We still run spamassassin, but with experience with setting both
dspam and spamassassin up, if I had to do it over again I would not
spend a minute on spamassassin.

>> But, seriously think about chucking
>> all that and just run greylist-milter.  It's in the ports I believe
>> but if not it's easy to compile and install.  And it is 100 times more
>> effective than spamassassin, content filtering, subject line
>> filtering,
>> you name it, I've tried it.
>
>I user a greylisting option made for exim and spamassassin.  It only
>greylists those things that spamassassin thinks is spam.  Yes, it
>uses the resources of running spamassassin first -- but it avoids
>lots of problems like the verizon callbacks, etc.  I don't have any
>exceptions set for it and we have not had problems with any servers
>sending us mail.  I have a separate box on a separate nic and private
>net doing clamd and spamassassin so the overhead of running
>spamassassin on everything that passes the callout sender
>verification does not affect the smtp box(es).
>
>We also set up to do our own callout sender verifications using exim
>on most incoming mail (based on some rules) and that greatly reduces
>the amount of spam to a trickle that even gets to the grey listing.
>And the stuff that makes it through the greylisting is 99.9999%
>tagged by spmassassin so the users can filter it if they want.
>

We do so much mail volume that I'm really not willing to fool with
callout sender verifiications.  It's just another thing to get wedged up.
Not to mention that some sites send from one IP address and receive
on another.  I don't know how you handle that but Verizon's way
of handling it is to assume that anything that sends smtp must receive
it, thus unless you setup for that, your going to get delayed mail
from them.  In other words Verizon's way of doing it is the bonehead
way.  Unfortunately Verizon is really big in our area and a lot of our
users have coorespondents that use verizon.net.

The beauty of the greylist milter over the way your doing it, is that
with
your method, the spammer is able to completely send the message to you.
Yes I realize the message gets killed in between your outside server and
your user's mailbox.  But, the spammer doesen't know that and they think
they have successfully sent a message.  Thus it encourages them to
keep sending.

With the greylist milter, the mailserver doesen't even let the sending
server
completely transmit a message to it.  So if the sending mailserver is a
compromised mailserver (like an open relay) the spam just piles up in
it's mailqueue and the sending server overflows and crashes.  If the
sender
is a compromised windows box, then the spammer either has to spend
5 minutes times the count of every spam mail he wants to send to us,
to send his spam to us, (which makes high volume transmission of mail
to us an impossible proposition) or he has to give up on us and move to
the next victim.  Either way, the spammer cannot avoid the direct
feedback
of "your spam isn't wanted here" and he gets a perfectly clear idea that
his sending to us won't be accepted on his terms.

Ted