Going farther in spam protection

[Robert Bartlett <rb...@digitalphx.com>]

Has anyone tried blocking by ip? Meaning I read somewhere you can block
access via the tcp.smtp file for qmail. Has anyone done this? If so is this
a good solution? Would you recommend this? If you do recommend this, then
what exactly do I look for in the headers to get the proper address to
block?

Thanks
Robert

Re: Going farther in spam protection

[Manuel Moeller <ma...@manuelm.org>]

Hi,

On Tue, Jul 20, 2004 at 07:28:56AM -0700, Robert Bartlett wrote:
> Has anyone tried blocking by ip? Meaning I read somewhere you can block
> access via the tcp.smtp file for qmail. Has anyone done this? If so is this
> a good solution? Would you recommend this? If you do recommend this, then
> what exactly do I look for in the headers to get the proper address to
> block?

We are using Postix with a hashmap of IPs that are blocked for the
reason having been used by spammers recently.

The list of IPs is generated by shell script which scans mail.log and
looks for "Recipient address rejected: User unknown in local recipient
table;" and "Relay access denied", filtered by some "sort" and "uniq -c"
to make sure only those IPs are hit, that sent plenty of spam.

HTH,
  Manuel

-- 
    Manuel Möller | Markusstrasse 31
   09130 Chemnitz | Fon: +49 151 127 174 28
  www.manuelm.org | manuelm@manuelm.org

Re: Going farther in spam protection

["Scot L. Harris" <we...@cfl.rr.com>]

On Tue, 2004-07-20 at 10:28, Robert Bartlett wrote:
> Has anyone tried blocking by ip? Meaning I read somewhere you can block
> access via the tcp.smtp file for qmail. Has anyone done this? If so is this
> a good solution? Would you recommend this? If you do recommend this, then
> what exactly do I look for in the headers to get the proper address to
> block?
> 
> Thanks
> Robert

I ran some analysis on spam messages received here and put the top dozen
IP addresses in the iptables rules to block smtp from those sites.  Had
a large number of hits in subsequent days from those IP addresses.  But
maintaining that would have become a nightmare.

I did find a solution that had dramatic results.  I implemented
milter-greylist.  This has reduced the number of spam messages that
spamassassin processes dramatically.  We went from 3000 to 6000 spam
messages a day to 3 to 8 spam messages a day.  

The basic concept is very simple but the results are way beyond what I
ever expected.  

During initial setup I made sure that we white listed known
correspondents so their email would not be delayed.  And I have since
reduced the default delay period so legit MTAs that retry quickly will
get their email through without a large delay.  

So far this has worked out great.  There are a couple of different
packages available to implement greylisting.  The one I chose was easy
to setup and does an excellent job. 

I know some have concerns over the delay and possibly the rejection of
legitimate email.  So far I have not run into problems with that.  YMMV.

Over all this in combination with spamassassin has allowed me to push
the spam problem to the far back burner so I can concentrate on other
problems (damn netgear VPNs....)

-- 
Scot L. Harris
webid@cfl.rr.com

operation failed because: there is no message for this error (#1014) 

Re: Going farther in spam protection

[Jonas Eckerman <jo...@frukt.org>]

On Tue, 20 Jul 2004 07:28:56 -0700, Robert Bartlett wrote:

>  Has anyone tried blocking by ip?

Yes. Calling relaydb from MIMEDefang, and feeding relaydb based on 
SpamAssassin results.

>  If so is this a good solution? Would you recommend this?

As long as you do it right, yes.

I manually check the dynamically generated list every now and then, as 
there's allways a risk it start blocking a good server because a user 
set up a .forward (or similar). I've manually whitelisted good servers 
from wich we get a lot of forwarded spam.

>  then what exactly do I look for in the
>  headers to get the proper address to block?

You have to analyze received headers.

/Jonas

-- 
Jonas Eckerman, jonas_lists@frukt.org
http://www.fsdb.org/