%i - total number of bytes read from client

%o - total number of bytes sent to client

%{fetch_hdr_count} - Number of mails with mail header data sent to

client

%{fetch_hdr_bytes} - Number of bytes with mail header data sent to

client

%{fetch_body_count} - Number of mails with mail body data sent to client

%{fetch_body_bytes} - Number of bytes with mail body data sent to client

%{deleted} - Number of mails where client added \Deleted flag

%{expunged} - Number of mails that client expunged

%{trashed} - Number of mails that client copied/moved to the

special_use=\Trash mailbox.

Any thoughts on what else would be useful?

Number of mails that have been \Seen ?

I have been running Dovecot with full debug logging so I am not aware if the same information is already available elsewhere in the log at production loglevel.

Paolo

Hi Timo,

Am 15.05.2015 um 13:59 schrieb Timo Sirainen:

http://hg.dovecot.org/dovecot-2.2/rev/93bba97afb2a http://hg.dovecot.org/dovecot-2.2/rev/e0a17714f0c9

So all in all, you can now add to imap_logout_format:

%i - total number of bytes read from client

%o - total number of bytes sent to client

%{fetch_hdr_count} - Number of mails with mail header data sent to client

%{fetch_hdr_bytes} - Number of bytes with mail header data sent to client

%{fetch_body_count} - Number of mails with mail body data sent to client

%{fetch_body_bytes} - Number of bytes with mail body data sent to client

%{deleted} - Number of mails where client added \Deleted flag

%{expunged} - Number of mails that client expunged

%{trashed} - Number of mails that client copied/moved to the

special_use=\Trash mailbox.

Any thoughts on what else would be useful?

I was also thinking about separating (deletes and) expunges from Trash vs non-Trash, but I'm not sure how useful that would be (and what would it be called?) It's also a bit annoying that a copy+expunge to a Trash will return expunged=1 trashed=1, but a move to Trash (via IMAP MOVE) will return expunged=0 trashed=1. But trying to fix that would be too much trouble. when imap_zlib is enabled, the %i and %o still show the uncompressed bytes. It could be very helpful to access the compressed bytes if the client used COMPRESS, so you can see which clients use COMPRESS, you can see/calculate a percentage (for information only), and if you want to do accounting and/or limit a users traffic, this would be very helpful to get the real amount of bytes travelling the line. Currently if a client uses COMPRESS, your accounting (by parsing the logfile) is wrong by maybe 50% or even more...

So maybe 4 new variables could be very helpful if imap_zlib is used:

• total number of compressed bytes read from client
• total number of compressed bytes sent to client
• percentage of compressed to uncompressed bytes read from client
• percentage of compressed to uncompressed bytes sent to client

If either imap_zlib is not enabled, or the client did not use COMPRESS, set everything to 0 (or "-" or something).

Thanks Michael