What do you monitor and alert on for your mailscanner system?

[Ken Anderson]

Furnish, Trever G wrote:

> I am wondering what the group generally monitors in order to detect problems
> with a mailscanner relay (ie things that should cause an alert to be sent to
> an admin).
>
> My system is probably a bit more isolated than most - my deployment
> (currently only testing) will *only* be intended for inbound mail filtering,
> no outbound delivery (not even for "no such user" bounces, if I can prevent
> it), so my list may not make sense in situations that handle outbound mail,
> but here are the conditions I'm planning to alert on so far - have I missed
> anything you monitor on you system?

Same here, with the exception that we have added previous 'no such user'
bounces with REJECT in sendmail access list. This keeps a lid on the
junk we are needlessly relaying to the mail hub, and the "Deferred" mail
that otherwise piles up in outgoing queues.

> Failure conditions to alert on:
> - Abnormally large inbound or outbound mailq.

Absolutely.
This is the first place some problems seem to be evident.

> - Deferred messages in the outbound mailq.  (I deliver only to an internal
> server over a lan link.)

Spam that is undeliverable (user unknown) to your mail hub will cause a
lot of "Deferred" and "Connection Refused" mail to pile up in your
outgoing gueues. We use the re-mqueue utility that comes with sendmail
to help with this issue, as well as some scripts that seek-and-destroy
these messages. That's why it's a good reason to either add all of your
users to the access db or REJECT common bad names ( previous users,
popular dictionary usernames ).

> - Deferred messages in the inbound mailq. (Not sure that even is possible.)

Never seen one. :-)

> - Old messages in the inbound or outbound mailqs (ie they haven't been
> accessed or modified in a while)

Rarely in the inbound queue, but those nasty "Deferred" and "Connection
Refused" emails will hang around for a while before sendmail deletes
them (4 days default) if you don't get them first.

> - MailScanner process count (too high or too low)

Never seen a problem with this.

> - Inbound sendmail process count.

On RedHat we do see old sendmail processes hanging around once in a
while. Not sure yet why this is..

> - Outbound sendmail queue runner (not sure how to differentiate in vs out
> yet though)

See /etc/rc.d/init.d/MailScanner if you installed via rpm. You'll see
the start sections for IN and OUT. That's a good place to get a handle
on it.

> - System unreachable via ping, smtp, http, or ssh (or whatever other methods
> are appropriate for your system)

Should have this as part of any system anyway...

> - Low disk space.

ditto.

> - High swap usage.

Avoid any. RAM is cheap.

> - High load average (especially anything nearing sendmail's deferal load
> average).

Should have this as part of any system anyway...

> - High process count.

How high is high? Never seen this be a problem. Load Avg will probably
be high before you reach "too high" a number of processes.

> - Dmesg errors (sends the dmesg output from the box to a monitoring device).

Should have this as part of any system anyway...

> - High filtering percentages (ie 100% spam).
> - Low filtering percentages (ie 10% spam).
> - Round trip of test messages - ie send a message to a bounceback address
> and expect it to return with X minutes.  Could also check to be sure a
> mailscanner header was found in the return message.

Use delay=x in maillog. It can be used to get an average & high time for
messages traveling through the system.

>
> Any suggestions for other things I could check?  If it breaks, I want to
> know *before* anyone else does. :-)
>

Security wise things can "break" too. Instead of just dmesg errors, run
a log analyzer (logwatch?) and tripwire if you have the time to
configure/update and read the reports. Logwatch will tell you what odd
error messages are showing up in the logs and tripwire will tell you if
anyone's been monkeying with your system.

Ken A.