About more verbose logging... (my only showstopper now)

On Sat, 06 Sep 2003 20:55:45 +0300, Timo Sirainen <tss@iki.fi> wrote:

O I use now a daemon which logs login (name, ip; as dovecot does), and

...

logout (with name, logout reason if any special) with the numbers of "read new mail number and size" and "mail left on server number and size".
Would be nice to have something like that in dovecot.

Could something like this be added for the next version?

Hmm. I think plugins should do that. No-one will agree on what they want to log anyway :) And the above is likely meant just for POP3 users.

Mainly it was meant for POP3 users, but IMAP debugging is just as expected. For example it's often useful to know whether a user was actually _able_ to read their mail, delete them or kept them as read, how many bytes did they transfer and what way was the connection closed.

Unfortunately it's pretty hard to tell a clueless end-user what the possible problem might have been when they have "no mail", "full mailbox" or "mail they never seen", if one can't see approximately what have happened. This stands for pop3 as well as for individual imap boxes (in the future for me, since there is no trusted imap servers so far).

But I think master process should actually handle logging the user's comings and goings so that they couldn't be faked. Especially logins from imap/pop3-login processes.. imap/pop3 processes could then just tell master process what extra stuff they want logged such as those mail counts and sizes.

Maybe master process should handle all logging anyway. Processes would just print to stderr which master process would redirect into proper log file..

Probably that's the best way (log important info by master, and generate stats and misc logs in plugins sent to the master). But.... could you please tell whether I should expect that in the near future, or shall I start worrying about being stuck with qpopper? :-o

(I do not have the time, but maybe I could try to help to write the plugin, or extend it, but it needs the internal code to handle it first anyway. No promise though...)

thanks, Peter