Re: Sendmail tweaks

On Tue, 29 Aug 2006, Matthew Schumacher wrote:

> You should look at this page:
>
> http://www.acme.com/mail_filtering/sendmail_config_frameset.html

The following are also good references (the last specifically for
miltering):

    http://www.sendmail.org/m4/indices.html
    http://www.sendmail.org/m4/tweaking_config.html
    http://www.mimedefang.org/

>> I've used QueueLA before, but it didnt' seem to 'queue' things so much as
>> 'deny new messages'. So, I'm a bit leery of that (And no, I didn't
>> confuse it with RefuseLA).
>
> I use RefuseLA and connection throttling. I don't allow any one host to
> chew up any significant resources, but if for some reason I am getting
> enough spam to get behind I refuse the messages. This causes my
> secondary MX to start queuing, allowing my primary to catch up.

QUEUE_LA allows the tcp connect, but doesn't print out the 220 line
immediately while the system load average is over the threshold you set.
REFUSE_LA refuses the tcp connect outright if the threshold is exceeded. I
use the both. QUEUE_LA doesn't deny messages, but if the load is such that
it can't process that item in the queue before the sending server times out
the connection it may appear to do that.

I use both. As a rule of thumb you will want to set QUEUE_LA between 2 and the
number of logical processors you have. REFUSE_LA I set to a couple of
higher.

As mentioned confCONNECTION_RATE_THROTTLE is essential, but so is
confBAD_RCPT_THROTTLE, confMAX_RCPTS_PER_MESSAGE, and all of the confTO_*
rules if you're trying to expire sessions as quickly as possible so more
potentially legitimate mail servers can connect.

> Speaking of the secondary mx, I use lots of strict RBLS on it. The
> reason is because most spammers send spam to the secondary MX thinking
> its not as tight as the primary so I make mine very picky about email.
> If the primary goes down I may get a few false positives, but during
> normal operation it is rejecting 90% of email as spam before it gets to
> my primary where I scan it with spamassassin.

I do filtering on all my MX hosts and insert a secret mail header on the
secondaries, so I don't bother refiltering on the primary (though you may
want to filter anyway if you're heavily reliant on self-training bayesian
databases). On the primary I remove that header so a user won't see it
and try to add it to bypass filtering.

In a nutshell, I do the full complement of filtering on all the servers
because a) depending on system load secondaries may start to "share" the
load and removing the need to filter on the primary for some messages makes
it easier to catch up and b) a lot of spammers deliberately target secondary
hosts to force them to attempt delivery of bounce messages to forged
addresses.

>> I believe that this version of sendmail (8.13.7) includes milter support,
>> I'm interested in milters. I know they are the bees knees, the cat's
>> pajamas, but unfortunately, the most popular, and one I was dying to use -
>> Greylisting - is unusable since mail on the domain I'm worrying about uses
>> postini. So, mail goes to postini, postini sends it to us. I can grey list
>> all I want, but postini is still gonna send it. The same goes for IP
>> blacklisting, connection throttles to stop spammers, and the like.
>> Postini is *the* only way into the mail server - any other connections are
>> rejected. (I do understand that I could throttle connections, but it's
>> not going to stop say, a spammer - the mail is already spooled on postini,
>> so it WILL come, the only thing that throttling will do is delay any
>> incoming mail.)
>
> If you don't want to use postini then cancel the service and do the spam
> filtering yourself.

Some spammers have gotten hip to the final destination server still being
"mail.foo.com" and the MX hosts being filtering services. Becuase of that
you may still see external delivery attempts straight to your mail host, in
which case grey listing & greet_pause can still be useful. Greet_pause can
still be selectively disabled via the access database for Postini.

>> As configured, sendmail already denies messages going to recipients that
>> don't exist; but because postini doesn't filter all mail (just ones that
>> are subscribed) a spam stomping milter that has a low false-positive rate
>> (since having someone on hand to do nothing but sort through messages
>> isn't useful) would also be good. And again: My only problem is I *am* on
>> solaris, and since glibc yhasn't been ported, any milter that is C/C++
>> that uses glibc is out of the question. Unless I want to port either
>> glibc, or the milter. Perl and python filters, while less desirable, are
>> acceptable.
>
> Get the management to sign off on putting a dedicated mail filter system
> in front of your sendmail box then run linux or bsd. Depending on your
> mail load, it shouldn't take much of a system to do it.

The majority of apps that are pure C (even Perl w/XS modules) compiles just
fine against Solaris libs. I don't see what glibc provides that you can't
already do with portable C. C++ compiled from source should also work just
fine *assuming* that the C++ libs you're compiling against were compiled
with the same compiler due to STL issues. Since libstdc++ is provided by
gcc and not glibc that shouldn't be a show stopper.

Tip about Perl XS modules w/Solaris- (or any other OS) provided Perl: even
though it was built with the proprietary compilers you can still build C XS
modules by editing Perl's Config.pm (usually
/usr/lib/perl5/{ver}/{platform}/Config.pm) and replace the compiler, flags,
link path, etc. I've personally done this on AIX, IRIX, and Solaris, and it
works for 80% of the modules I've tried with no problems.

         --Arthur Corliss
           Bolverk's Lair -- http://arthur.corlissfamily.org/
           Digital Mages -- http://www.digitalmages.com/
           "Live Free or Die, the Only Way to Live" -- NH State Motto
---------
To unsubscribe, send email to <aklug-request@aklug.org>
with 'unsubscribe' in the message body.
Received on Tue Aug 29 19:03:40 2006