[Dovecot] Feature request: more log info/stats
Hello,
even though Timo seems to be hibernating (it's not _that_ cold in ole Suomi ;) I'd like to beg for a feature that would be very much appreciated over here. If something like this is already present and eluded my thorough archive and doc searches, feel free to smack me and then point me to the right direction.
Feature request: More extensive session information and statistics in the logs.
Currently all I can get from dovecot is login information, there's not even a log entry when a session was ended either by the client or a timeout. In addition a short summary would be be very helpful, qpoppers one liner stats come to mind like this:
Apr 12 05:30:30 test in.qpopper[21266]: Stats: test 6 21868 2 108126 some.do.main IP.AD.DR.ES [pop_updt.c:296]
Stating that user test downloaded/deleted 6 mails with 21868 bytes total and kept 2 in the inbox. This might be expanded on for IMAP operations like moves or such and raw data about transferred bytes in/out added (in my case I get that info from perdition), but the really important parts are:
When did a user log into the server, when did that session end? How many new mails were read and how many mails deleted during that session?
The rationale is that with this info at hand the (unfortunately) very common user whining along the lines of "the mail server ate my mails" or "I never saw this mail!" are much easier to refute.
Regards and keep up the good work,
Christian Balzer
Christian Balzer Network/Systems Engineer NOC chibi@gol.com Global OnLine Japan/Fusion Network Services http://www.gol.com/
On Fri, 16 Apr 2004, Christian Balzer wrote:
Stating that user test downloaded/deleted 6 mails with 21868 bytes total and kept 2 in the inbox. This might be expanded on for IMAP operations like moves or such and raw data about transferred bytes in/out added (in my case I get that info from perdition), but the really important parts are:
When did a user log into the server, when did that session end? How many new mails were read and how many mails deleted during that session?
The rationale is that with this info at hand the (unfortunately) very common user whining along the lines of "the mail server ate my mails" or "I never saw this mail!" are much easier to refute.
I was just thinking about this yesterday. I would second this request; it is sometimes really useful to be able to see how many mails were downloaded and how many were left on the server in a session.
Jethro.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Jethro R Binks Computing Officer, IT Services University Of Strathclyde, Glasgow, UK
Here here!! =)
Jethro R Binks wrote:
On Fri, 16 Apr 2004, Christian Balzer wrote:
Stating that user test downloaded/deleted 6 mails with 21868 bytes total and kept 2 in the inbox. This might be expanded on for IMAP operations like moves or such and raw data about transferred bytes in/out added (in my case I get that info from perdition), but the really important parts are:
When did a user log into the server, when did that session end? How many new mails were read and how many mails deleted during that session?
The rationale is that with this info at hand the (unfortunately) very common user whining along the lines of "the mail server ate my mails" or "I never saw this mail!" are much easier to refute.
I was just thinking about this yesterday. I would second this request; it is sometimes really useful to be able to see how many mails were downloaded and how many were left on the server in a session.
Jethro.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Jethro R Binks Computing Officer, IT Services University Of Strathclyde, Glasgow, UK
Feature request: More extensive session information and statistics in the logs.
Yep- I think this is a common suggestion :-)
Not to mention some more information in the entries that report errors. For example, when I see
Apr 16 07:11:26 mercury dovecot-auth: passwd(xxxxx): unknown user
repeated 10,000 times, I would like to have a handle on what IP address that login is coming in on, so I can call the person and get the problem fixed.
Ditto with the "disconnected" or "aborted" or whatever-- some way to tie the reports to the source or the login.
mm
On Fri, 2004-04-16 at 11:32, Christian Balzer wrote:
Feature request: More extensive session information and statistics in the logs.
I've thought about doing this with a plugin, so everyone can decide what exactly they want to log. The plugin API should probably be changed in some way to support this more easily..
[He lives!]
Timo wrote:
On Fri, 2004-04-16 at 11:32, Christian Balzer wrote:
Feature request:=20 More extensive session information and statistics in the logs.
I've thought about doing this with a plugin, so everyone can decide what exactly they want to log. The plugin API should probably be changed in some way to support this more easily..
I'm sure I can mobilize some local talent to work on a plugin once the API is in what you would deem a stable state.
Regards,
Christian Balzer
Christian Balzer Network/Systems Engineer NOC chibi@gol.com Global OnLine Japan/Fusion Network Services http://www.gol.com/
On Tue, 2004-04-27 at 09:13, Christian Balzer wrote:
Feature request:=20 More extensive session information and statistics in the logs.
I've thought about doing this with a plugin, so everyone can decide what exactly they want to log. The plugin API should probably be changed in some way to support this more easily..
I'm sure I can mobilize some local talent to work on a plugin once the API is in what you would deem a stable state.
I think writing the plugin itself doesn't take more than few minutes when there's simple API for it. It's the API designing that takes time..
I think lib-index API is pretty great now, mail-storage API needs some heavy redesigning, and imap/pop3-specific plugin API hardly exists yet. What would it need? At least make it possible to replace, extend or just transparently hook into existing commands (pre, post, somewhere-in-the-middle?) and create new commands. Creating and replacing already works. Figuring out how extending works could be tricky. Mail-storage API already allows hooking into it. What else? ..
participants (5)
-
Christian Balzer
-
James Moser
-
Jethro R Binks
-
Mark E. Mallett
-
Timo Sirainen