From Bugzilla Helper: User-Agent: Mozilla/4.77 [en] (X11; U; Linux 2.2.12 i686) Description of problem: I agree that UW-imap is not an ideal software pkg, but there doesn't seem to be a better alternative that uses standard mbox files. My only real complaint is that when user-clients check for mail every few minutes, the imap entries wind up flooding the standard log files. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. Install imap-xxx.rpm 2. Have some folks point outlook-express at your server. 3. Try to find the 'non-imap' messages in /var/log/secure and /var/log/maillog :-) Additional info: Cleaning up /var/log/secure is easy - just add the line log_type = FILE /var/log/imap.log to the appropriate files in /etc/xinetd.d/ --- /var/log/maillog is more troublesome. One possible fix is to hack imapd to change its syslog facility from LOG_MAIL to, eg, LOG_LOCAL1, and then use /etc/syslogd.conf to re-direct the messages. But this fix would not really be an appropriate for a distribution (what if every package wanted to use LOG_LOCAL1 ?). A better fix is to have imapd, etc, accept an optional command-line argument giving the name of a log file, and then have messages go directly to the file (and if no logfile is given, continue to use syslog with LOG_MAIL). Then the clutter can be eliminated by also adding server_args = --logfile=/var/log/imap.log to the appropriate /etc/xinetd.d/ files. --- I've implemented the above change in about 90 lines of code. I'm planning to send it upstream to Mark Crispin at UW. But my code assumes that libc has working getopts_long() and strftime() functions, so he may be less than enthusiastic. Please let me know if you might be interested in including this fix in the redhat rpm. If so, I'll clean things up a bit (and add patches for the man pages and spec file) and submit it as an attachment. Cheers, -Jeff Norden
The best solution I can think of is to use logrotate to compress and rotate the logs at a frequency that is useful. Alternatively, run a cron job to filter the logs for what is wanted/not wanted. Changing the LOG facility to LOG_LOCAL1 would violate standard expected behaviour, as well as possibly violating published standards I would presume. It would also fork our imap package from the upstream maintainer's version, and I am not willing to do that. This proposed change, while it may solve the problem for you, is not a proper solution. The problem isn't the imap server IMHO, but rather the logging services themselves. syslog in particular. I doubt Mark Crispin will change the log level as you suggest either because by definition LOCAL* log levels are for the local system administrators usage, and are not to be used by system supplied packages. I just fixed a bug in xfs from using LOCAL0, and if upstream were to incorporate this change, I would have to remove it on our end. Sorry, but a proper solution to this needs to be found that does not interefere with standards, nor expected behaviour. Again, I suggest using a log parsing script via cron and/or logrotate.
Sorry, I guess the end of my post wasn't quite clear. I fully agree that using a LOCALn log level is *not* an appropriate fix (except as a local hack). What I've written is a patch that *allows* impad to send messages directly to a file, much the same as specifying 'log_type = FILE' to xinetd. Starting the server with 'impad --logfile=/var/log/imap.log' causes all messages to go directly to imap.log, and not through the syslog routines at all. Starting the server without the logfile option gives the old behavior of using syslog with the LOG_MAIL facility. So there should be no problem with standards or compatibility. Please let me know if you'd like me to clean up and submit the patch. I also agree that the root of the problem lies in the current implementation of syslog altogether. It would be nice to be able to specify in syslog.conf that all messages from a specific daemon should go to a specific file. But that won't be easy to do. It would require changing *both* syslogd *and* the syslog/openlog routines in glibc, because the current syslog subroutine only passes the priority/facility information to syslogd. There would be two serious obstacles to deal with: (1) backward compatibility with the BSD syslog standard, and (2) performance - it would probably be bad to make syslogd parse and lookup an identity string for every logged message.