Bocking IP's rather than Email domains

[Craig White]

On Fri, 2006-02-17 at 21:13 -0500, CodeHeads wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> On Fri, February 17, 2006 9:05 pm, Craig White wrote:
> > On Fri, 2006-02-17 at 20:54 -0500, CodeHeads wrote:
> >> -----BEGIN PGP SIGNED MESSAGE-----
> >> Hash: SHA1
> >>
> >> Hello all,
> >> Have a question:
> >> Would it be better to block IP's instead of domains for an email server?
> >>
> >> I guess would be that the person can change the domain in their reply
> >> email address, so blocking IP ranges would be better, wouldn't it??
> >>
> >> Example:
> >> IP range = 222.168.0.0 - 222.169.255.255 (Actual spammer IP)
> >>
> >> Wouldn't be better to place the IP's in iptables?? Or would another
> >> option
> >> be better?
> >>
> >> I hope this was not discussed at a later date. Just curious on what the
> >> IT
> >> fields thinks of this. :)
> > ----
> > Sure - use a hammer when the task at hand calls for a screwdriver. It's
> > your mail server so use the hammer if that pleases you. That won't
> > however stop the next ip range from sending you spam.
> >
> > Configure the mail server properly...
> > greylist
> > MTA with good RBL settings
> > wrapper program [MailScanner | Mime-Defang | Amavisd-new]
> >  wrapper to control spamassassin & anti-virus (i.e. clamav)
> >
> > spam would be minimal
> >
> > Craig
> >
> > fwiw, I would recommend postfix/mailscanner/clamav/postgrey but other
> > qualified opinions would recommend other things
> 
> 
> Craig,
> I am running the following:
> Qmail, qmail-scanner, ClamAV, Spamassassin, maildrop. I should have posted
> that in the first email. :)
> 
> I will search on google for greylisting setup but is there a how to for
> setting up grey listing on qmail??  Sorry, just learning the linux mail
> server stuff.
> 
> Thanks for the advice! :)
----
probably a good thing you didn't post that to the list as contentious as
it is the last few days or we would have had a lot of people do the 'oh
don't use Qmail' thing. On second thought...I am gonna post this to the
list because some of these issues are worthy of discussion.

To be honest...I don't know about Qmail - and greylisting is very much
tied to the MTA that you use so the best thing to do if you want to
implement greylist would be to use Qmail resources
(lists/forums/whatever).

You probably should implement some RBL's in Qmail and I wouldn't know
how to do that either - I can get them installed in Sendmail but I have
pretty much abandoned Sendmail these days for Postfix which seem to be
the ultimate in configuration options. 

You can implement RBL's within spamassassin/qmail-scanner I think but by
that time, it's too late as you have already received the mail.

Over the past 2 years, I have migrated my setup to be very heavy on
qualifying what I accept at the MTA level...

the first thing is greylisting which simply defers original mail
delivery based upon what are knows as tuples...

sender/senders smtp server/recipient - the first time this exact
combination occurs on an inbound mail, the local MTA sends back a TEMP
FAIL error, which tells the sending SMTP connection to try again soon.
If the SMTP connection is truly a SMTP server, it will queue the message
for delivery in another 15 minutes or so. If it is a system corrupted by
some worm or hacker and just spitting out email, it isn't going to store
these messages and try later, it's just going to move on.

The second level of defense I employ is delivery restrictions on a wide
variety of things such as RBL's, reverse DNS verifiable SMTP server,
mail to an actual account on my box.

Between these two layers, I have knocked out a tremendous amount of
inbound email that I have refused to accept. Then it is passed to a
wrapper (I use MailScanner) which is put through spamassassin, clamav
and a wide variety of scanning for phishing fraud, objectionable
attachments, etc. - all controlled by the wrapper.

At that point, email that gets through is delivered locally. Emails that
score 6 -> 14 on spamassassin are put into users INBOX.SPAMBOX by sieve
scripts that are automatically installed for each user as his mailbox is
created. High scoring spam mail are simply filed in the giant bit bucket
in the sky. This provides protection for false positives (for which I
see very few but I did have this client who had some chick sending him
all HTML mails from a hotmail account using a dial-up and that would be
enough to get her into the 6 - 7 range in spamassassin so I finally just
whitelisted her.

One of the more amusing things about all this is that after I have
implemented this type of setup for a client, 2 of them have called me
worrying that their email isn't working because they weren't getting any
spam and in a twisted sense, people now expect spam in their inbox and
if they don't see spam in their inbox, they worry that their email
system is broken.

I hope this helps someone. Personally, I wouldn't recommend Qmail as
some of these options are awkward to implement not to mention that Qmail
stuff simply isn't GPL and therefore flies in the face of the best
things that Linux can offer.

Craig