Peter J. Holzer wrote:
This patch increases the log level of the SMTP dialog from LOGDEBUG to
LOGINFO. My log analysis scripts use the SMTP dialog as input and the
debug files really grow too fast at log level 8.
NOTE: Don't use numeric log levels. Please use the LOG* constants instead so
that all code is self-documenting. You'll also note that LOGDEBUG internally is
now 7 and not 8 (I got rid of LOGRADAR during the logging plugin
implementation). I think the syslog levels have been kind of abused over the
years, and we might want to make a clean break with that tradition and come up
with a better way to delineate what we are logging (not a complete set by any
means):
LOGPROTOCOL - very low level logs (like the SMTP conversation)
LOGINFO - higher level but still detailed (like transitions between SMTP phases)
LOGERROR - a plugin couldn't continue (needs to be fixed)
LOGWARN - a harmless error or other warnings from external apps
LOGWHINE - qpsmtpd had to work around something that was missing that you might
want to fix, but it will work without problem until then
LOGSUCCESS - something went right for a change
LOGDENY - qpsmtpd correctly blocked a message for some reason (it's not really a
warning because everything is working fine, just the message violated the site's
profile)
LOGVIRUS - this may be important enough an event to justify it's own category
(so you can compare how your various scanners are doing against each other)
Basically, rather than viewing logs as being on a continuum from harmless to
severe (and around the bend to compulsive), collect the log lines by what /sort/
of thing they are logging. This would make it easier to extend to logging some
other sort of thing, rather than trying to shoehorn it into the existing framework).
That being said, I'm inclined not to apply this patch (it looks like Ask already
applied everything except the SIGCHLD and this one already), because IMO the
SMTP-level conversation really is a LOGDEBUG sort of thing.
OTOH, quite a few
messages at level LOGINFO or higher could IMHO be demoted to LOGDEBUG.
I've been trying to go through and tweak the log levels around to be more
consistent across plugins (I think they are pretty consistent in the core now),
since there were many authors. Patches accepted for discussion!
Maybe this is obsolete now that we have logging plugins - I haven't
looked at them yet.
Yeah, you could definitely use the logging plugins to make this easier to manage
(say by using a !processor directive on the detailed logs as they quickly rotate
away, yet saving a second set of lower level logs for a longer time).
John
