dovecot - Apr 2004 - 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 at 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

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL:
<http://dovecot.org/pipermail/dovecot/attachments/20040426/c1ba1a03/attachment-0001.bin>

[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 at gol.com   	Global OnLine Japan/Fusion Network Services
http://www.gol.com/