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