nagios and sendmail log entries (did not issue MAIL/EXPN/VRFY/ETRN)

[Paul L. Allen]

Others have already commented but Marc and Andreas both seemed to miss
what I think is the crux of the matter. 

Marcus Sobchak writes: 

> nagios generates the follwing maillog entry each time it checks my 
> sendmail
[...]
> Any ideas how to disable this and make nagios doing a quite and silent
> job?

This is the important thing the other two did not say.  Nagios does NOT
generate that entry.  Sendmail generates that entry.  Read those two
sentences again until you understand them.  Nagios does things that
causes sendmail to generate that entry, but it is sendmail's design
decision that it generates that entry in response to what Nagios does.  I
cannot see any utility in logging that detail in the normal course of
events although I can see it might be useful to have in some situations
and would hope to be able to switch on some level of debugging temporarily
in order to get it. 

Marc wondered why Andreas said sendmail was not compliant with the RFCs,
and I agree with what I read into the implications of Marc's question:
sendmail logging that detail is NOT in breach of the RFCs.  The RFCs
details the protocols that take place on port 25 and the format of mail
messages; they say absolutely nothing about what, if anything, should
be logged.  Nor do they say whether or not your MTA should be able to
display how many mails are in its queue, nor do they say whether or not
your MTA should send you a Yahoo message for every mail that is
successfully received by your system, nor do they say whether or not your
MTA should trigger an interface that gives you a painful electric shock
whenever mail could not be delivered, nor...  The logging detail, and those
other things, are all decisions about the design of the MTA you use and
one option you have if you do not like the consequences of those design
decisions is to switch to a different MTA. 

Nor is there any failure to comply with RFCs if sendmail logs that sort of
thing at a level I would consider to be stupid.  That sort of detail is
(depending on your viewpoint) an informational message or (just perhaps) a
warning message.  But if sendmail chooses to log it as a critical message
or even (if your OS supports it) at a level of "the world is about to end
so get ready to meet your maker" then that is sendmail's decision (possibly
configurable in some way by you) and it is your choice as to whether or not
you even read the logs at all, let alone whether or not you bother to read
entries of that type. 

If I were in your situation I'd just ignore those entries.  If I had a
need to process the logs in some way then I'd do some scripting so the
processing ignored those entries.  And if there were so many of those
entries that they really cluttered up the mail log then I'd find out how
to stop sendmail from logging that kind of thing or switch to another MTA. 

What Andreas alluded to, but didn't fully explain, is that the new release
of check_smtp will not only stop those log entries happening but actually
does a better test of the functioning of your MTA. If the partition holding
your mail spool is full then the check_smtp you're using will probably say
everything is fine when actually your system isn't accepting mail.  The
reason for upgrading is not that it would eliminate those (in my opinion)
entirely trivial and ignorable log entries but that it would do a more
thorough check that your MTA really is working as it should.  Of course,
the only way to be sure is to send test mails to every user at every
domain on the server and check that each of those mails is delivered
successfully. 

There are always trade-offs, but something that checks you get a connection
banner is only slightly better than checking the port is open.  Each
additional test of functionality gives you more assurance things are
working correctly.  Big Brother checks port 25 is accepting connections.
The plugin you're using checks you get a connection banner, which is an
improvement.  Checking you get a sensible response to HELO or EHLO is
yet another improvement.  Etc. 

-- 
Paul Allen
Softflare Support 




-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Nagios-users mailing list
Nagios-users at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nagios-users
::: Please include Nagios version, plugin version (-v) and OS when reporting any issue. 
::: Messages without supporting info will risk being sent to /dev/null