dovecot - Aug 2013 - proxy: get rid of redundant log-informations

Hi

login_log_format_elements = user=<%u> method=%m rip=%r %k

is it possible to get rid of the "proxy(test at testserver.rhsoft.net):
started proxying to 127.0.0.1:143: " part
because on a proxy-only server i know that and it is explicitly not listed in
"login_log_format_elements"

as well as for the "TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA" it
would be enough "TLSv1 DHE-RSA-CAMELLIA256-SHA"

the reason is simple:
* all needed informations are present
* smaller logfiles
* nicer "tail -f" on the syslog without breaks
_____________________________________________

Aug 14 16:31:46 testserver dovecot: imap-login: proxy(test at
testserver.rhsoft.net): started proxying to
127.0.0.1:143: user=<test at testserver.rhsoft.net>, method=CRAM-MD5,
rip=91.118.73.99, TLSv1 with cipher
DHE-RSA-CAMELLIA256-SHA (256/256 bits)




-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 263 bytes
Desc: OpenPGP digital signature
URL:
<http://dovecot.org/pipermail/dovecot/attachments/20130814/d674982f/attachment.bin>

Am 14.08.2013 16:37, schrieb Reindl Harald:
> Hi
> 
> login_log_format_elements = user=<%u> method=%m rip=%r %k
> 
> is it possible to get rid of the "proxy(test at
testserver.rhsoft.net): started proxying to 127.0.0.1:143: " part
> because on a proxy-only server i know that and it is explicitly not listed
in "login_log_format_elements"
> 
> as well as for the "TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA" it
would be enough "TLSv1 DHE-RSA-CAMELLIA256-SHA"
> 
> the reason is simple:
> * all needed informations are present
> * smaller logfiles
> * nicer "tail -f" on the syslog without breaks
> _____________________________________________
> 
> Aug 14 16:31:46 testserver dovecot: imap-login: proxy(test at
testserver.rhsoft.net): started proxying to
> 127.0.0.1:143: user=<test at testserver.rhsoft.net>, method=CRAM-MD5,
rip=91.118.73.99, TLSv1 with cipher
> DHE-RSA-CAMELLIA256-SHA (256/256 bits)
got it

login_log_format_elements = user=<%u> method=%m rip=%r %k
login_log_format          = %s

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 263 bytes
Desc: OpenPGP digital signature
URL:
<http://dovecot.org/pipermail/dovecot/attachments/20130814/daa55bd5/attachment.bin>

On 14.8.2013, at 17.37, Reindl Harald <h.reindl at thelounge.net> wrote:
> login_log_format_elements = user=<%u> method=%m rip=%r %k
> 
> is it possible to get rid of the "proxy(test at
testserver.rhsoft.net): started proxying to 127.0.0.1:143: " part
> because on a proxy-only server i know that and it is explicitly not listed
in "login_log_format_elements"
Different people want different things logged. I think if I started adding
settings to control those from Dovecot configuration it would quickly become a
horribly complex mess. An alternative could be to send logging through a more
configurable log process. Like perhaps a simple perl log proxy where you can do
whatever you want using regexps and such.. This is already possible if someone
just writes such a log proxy, although it would be a bit annoying as it would
have to implement Dovecot's internal master service protocols. A somewhat
easier way would be if Dovecot's log process supported a filtering service,
similar to how the mail-filter plugin works for emails. Then you could use
whatever scripting language you want to implement the filters and if the filter
breaks or is too slow, the log process could just drop it and continue logging
without filtering.

The main problem I see with such a generic log filter is that it operates on a
full log line string. Maybe for your use case it would be enough, but people
have wanted other things as well where such a filter could be helpful, like
logging things to SQL database. But there it would be useful to have some kind
of key=value pairs of data, like username=foo mailbox=bar without having to
parse it from the text, which could be difficult to do 100% correctly. So maybe
some day Dovecot's whole logging system could be redesigned to support that
as well.

Anyway, all of this is something that I don't see myself having time to
implement anytime soon.