Re: Sendmail tweaks

Adam Bultman wrote:
> Since the thread about MTAs brought up some of the usual wars, and I
> happen to be managing a few sendmail servers (despite my affinity for
> other MTAs): What is iit that you put in
> your MC file and any other tweaks that you put in your cf file to "speed"
> things up and manage queue sizes?

You should look at this page:

http://www.acme.com/mail_filtering/sendmail_config_frameset.html

>
> 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.

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 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.

>
> 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.

>
>
> So: if you have any tips, feel free to send them on. As I mentioned in
> the other thread, I'm looking to move, but since this would be a LARGE
> move, I have to make do with what I have until I have new servers built
> and ready and a migration plan written out and tested. (Hey - if you have
> migration plans... well.. post those, too).

There is more, but the biggest things are getting some milters running.
 The more efficient the milter is and the earlier in the process it
detects the spam the better it will work.

> I mostly need to get away fro mbox format, as mbox format is not NFS safe,
> and the current "nfs safe" version of procmail wwe have is undesirable.

I don't know of any mail system that is NFS safe except for
qmail/maildir. If you must use NFS your stuck. You really should look
into iscsi or local disks or something, NFS is really a bad idea when it
comes to mail.

>
> Feel free to bounce ideas, flame, whatever.

Okay, ditch solaris/nfs, or purchase Sun's mail solution. If your going
to run opensource tools, you really are better off on linux/bsd.

schu

---------
To unsubscribe, send email to <aklug-request@aklug.org>
with 'unsubscribe' in the message body.
Received on Tue Aug 29 17:16:45 2006