[Mimedefang] Re: MTA

[G.W. Haywood]

Hi there,

On Fri, 18 May 2007 Joseph Brennan wrote:

> > On Thu, May 17, 2007 at 10:56:50AM -0400, Daniel Aquino wrote:
> >> I wonder what type of tests are  you guys performing at the MTA level
> >> that will subvert any extra processing that would occur with
> >> mimedefang ?
> >
>
> 1. greet_pause

I use a loooong pause, sometimes I have to remove it for specific hosts
or domains that can't handle it.

> 2. ratecontrol
> 3. BAD_RCPT_THROTTLE
> 4. If sender address is string at columbia.edu, check users and aliases,
> and accept only if it is a valid address.  Done in sendmail because it
> can check users and aliases quickly.

The sendmail access database is very good.  I set a maximum number of
connections (ClientConn in the access database) and block a fairly
large number of TLDs and ISPs in there.  (Don't forget to rebuild the
access.db file after editing the access text file. :)

> 5. If nbadrcpts reaches 3, start tempfailing...

I also use MAXBADCOMMANDS=2 instead of the default 25 in srvrsmtp.c
although this is triggered far less often lately.  I don't know why,
maybe the spammers are reacting.

> RBLs are done in Mimedefang, so that we can write in exceptions...

I use milters a lot, in particular I do RBL checks before the more
expensive perl-based processing is done (mimedefang, spamassassin).
Here are the milters used on the mailservers that I run, in the order
in which they appear in sendmail.cf:

rcptfilter
spfmilter
chainmail
milter-regex
dnsbl
greylist
clmilter
mimedefang

I try to call the really processor-intensive milters are called later
than those which can give a rejection quickly.

Probably milter-regex, greylist and dnsbl do the most work, probably
in that order.  Mimedefang and clamav (clmilter) rarely get to do very
much except at one site where there are a few - shall we say - less
responsible Internet users.

In addition to what you might call application-layer stuff like this I
block a great deal of junk using dynamic iptables rules generated by a
few scripts which monitor the logs for suspicious activity.  This also
keeps the logs more manageable, so it isn't such a pain to look at them
when it's necessary.

The net result is the virtual elimination of spam.  I can't give a
very accurate figure for the fraction which gets through, but it is of
the order of 0.00001 percent.  I do have occasional issues with people
who use (I'll be careful with my words here) ISPs known for spam
problems.  There are many ISPs from who all attempts to send mail - in
fact all connection attempts - are rejected by my servers.  That
doesn't keep me awake at night, but it does mean that my approach
isn't for everyone.

--

73,
Ged.