Log table

Yes, we just haven't done it yet.

On Wed, 2007-08-29 at 23:24 +0100, Jorge Bastos wrote:
> Hi,
> I'd like to have 2 tables, with the logs for logins for
pop and imap,
> with fields:
>  
> user,datetime,ip,server (with values pop or
imap),action (with values
> login or exit),bytes_transfered (althrou this cound
will only be
> eficient for pop3)
>  
> There, with a 2 parameters per secction, one for pop
and other for
> imap, to enable log or not.
>  
> Would this be possible with dbmail?
>  
>  
> Jorge
> _______________________________________________
> DBmail mailing list
> DBmaildbmail.org
> htt
ps://mailman.fastxs.nl/mailman/listinfo/dbmail

_______________________________________________
DBmail mailing list
DBmaildbmail.org
htt
ps://mailman.fastxs.nl/mailman/listinfo/dbmail

On Donnerstag, 30. August 2007 Jorge Bastos wrote:
> user,datetime,ip,server (with values pop or
imap),action (with values
> login or exit),

d'accord.

> bytes_transfered (althrou this cound will only be 
> eficient for pop3)

Why? It'd be nice for imap too, to see the traffic that
users are 
producing. By that, you can see from the logs who your power
users are.

I'd also like a field messages_transferred, mostly for pop,
but also 
possible for imap I guess.

A "status" field is also needed, saying
"success" or "error" or 
something, to see if accounts are probed.

"duration" to see how long the connection lasted.

Maybe another flag to see if IMAP IDLE was used, or other
various stuff 
that could be of help finding errors, bugs, performance
problems.

I don't know if/when such logging is going to happen, just
wanted to 
document my thoughts, because if it's done it should be
really helpful.

See thread "Re: [Dbmail] POP/IMAP logging via
syslog" my mail from 9. 
August 2007 about the too much logging that happens
currently. That 
should be fixed first, I suppose.

mfg zmi
-- 
// Michael Monnerie, Ing.BSc    -----      http://it-management.at
// Tel: 0676/846 914 666                     
.network.your.ideas.
// PGP Key:         "curl -s http://zmi.at/zmi.asc | gpg
--import"
// Fingerprint: EA39 8918 EDFF 0A68 ACFB  11B7 BA2D 060F
1C6F E6B0
// Keyserver: www.keyserver.net                   Key-ID:
1C6FE6B0

_______________________________________________
DBmail mailing list
DBmaildbmail.org
htt
ps://mailman.fastxs.nl/mailman/listinfo/dbmail

Cool,
I've add something to the wiki, don't know if it's ok, you
and anyone can
change if something is wrong.

-----Original Message-----
From: dbmail-bouncesdbmail.org [mailto:dbmail-bouncesdbmail.org] On Behalf
Of Aaron Stone
Sent: quinta-feira, 6 de Setembro de 2007 3:24
To: DBMail mailinglist
Subject: Re: [Dbmail] Log table

Yes, we just haven't done it yet.

On Wed, 2007-08-29 at 23:24 +0100, Jorge Bastos wrote:
> Hi,
> I'd like to have 2 tables, with the logs for logins for
pop and imap,
> with fields:
>  
> user,datetime,ip,server (with values pop or
imap),action (with values
> login or exit),bytes_transfered (althrou this cound
will only be
> eficient for pop3)
>  
> There, with a 2 parameters per secction, one for pop
and other for
> imap, to enable log or not.
>  
> Would this be possible with dbmail?
>  
>  
> Jorge
> _______________________________________________
> DBmail mailing list
> DBmaildbmail.org
> htt
ps://mailman.fastxs.nl/mailman/listinfo/dbmail

_______________________________________________
DBmail mailing list
DBmaildbmail.org
htt
ps://mailman.fastxs.nl/mailman/listinfo/dbmail

_______________________________________________
DBmail mailing list
DBmaildbmail.org
htt
ps://mailman.fastxs.nl/mailman/listinfo/dbmail

This would be more consistant if the log values are writen
by dbmail instead
of catching them on syslog.

(mailing list alive again :P)


-----Original Message-----
From: dbmail-bouncesdbmail.org [mailto:dbmail-bouncesdbmail.org] On Behalf
Of Michael Monnerie
Sent: quinta-feira, 6 de Setembro de 2007 9:00
To: DBMail mailinglist
Subject: Re: [Dbmail] Log table

On Donnerstag, 30. August 2007 Jorge Bastos wrote:
> user,datetime,ip,server (with values pop or
imap),action (with values 
> login or exit),

d'accord.

> bytes_transfered (althrou this cound will only be
eficient for pop3)

Why? It'd be nice for imap too, to see the traffic that
users are producing.
By that, you can see from the logs who your power users
are.

I'd also like a field messages_transferred, mostly for pop,
but also
possible for imap I guess.

A "status" field is also needed, saying
"success" or "error" or something,
to see if accounts are probed.

"duration" to see how long the connection lasted.

Maybe another flag to see if IMAP IDLE was used, or other
various stuff that
could be of help finding errors, bugs, performance
problems.

I don't know if/when such logging is going to happen, just
wanted to
document my thoughts, because if it's done it should be
really helpful.

See thread "Re: [Dbmail] POP/IMAP logging via
syslog" my mail from 9. 
August 2007 about the too much logging that happens
currently. That should
be fixed first, I suppose.

mfg zmi
-- 
// Michael Monnerie, Ing.BSc    -----      http://it-management.at
// Tel: 0676/846 914 666                     
.network.your.ideas.
// PGP Key:         "curl -s http://zmi.at/zmi.asc | gpg
--import"
// Fingerprint: EA39 8918 EDFF 0A68 ACFB  11B7 BA2D 060F
1C6F E6B0
// Keyserver: www.keyserver.net                   Key-ID:
1C6FE6B0

_______________________________________________
DBmail mailing list
DBmaildbmail.org
htt
ps://mailman.fastxs.nl/mailman/listinfo/dbmail

On Thu, 2007-09-06 at 09:59 +0200, Michael Monnerie wrote:
> 
> I'd also like a field messages_transferred, mostly for
pop, but also 
> possible for imap I guess. 

For IMAP it might be nice to know both messages retrieved
(or I guess
message parts, as you don't have to retrieve the whole
thing, do you?)
and messages APPENDed separately.  Probably even byte
counters for
up/down would be useful there.

-- 
Jesse Norell
Kentec Communications, Inc.
jessekci.net
_______________________________________________
DBmail mailing list
DBmaildbmail.org
htt
ps://mailman.fastxs.nl/mailman/listinfo/dbmail

I'd love to have that extra info too.


----- Original Message ----- 
From: "Jesse Norell" <jessekci.net>
To: "DBMail mailinglist" <dbmaildbmail.org>
Sent: Monday, September 10, 2007 6:10 PM
Subject: Re: [Dbmail] Log table


> On Thu, 2007-09-06 at 09:59 +0200, Michael Monnerie
wrote:
>> 
>> I'd also like a field messages_transferred, mostly
for pop, but also 
>> possible for imap I guess. 
> 
> For IMAP it might be nice to know both messages
retrieved (or I guess
> message parts, as you don't have to retrieve the whole
thing, do you?)
> and messages APPENDed separately.  Probably even byte
counters for
> up/down would be useful there.
> 
> -- 
> Jesse Norell
> Kentec Communications, Inc.
> jessekci.net
> _______________________________________________
> DBmail mailing list
> DBmaildbmail.org
> htt
ps://mailman.fastxs.nl/mailman/listinfo/dbmail
>
_______________________________________________
DBmail mailing list
DBmaildbmail.org
htt
ps://mailman.fastxs.nl/mailman/listinfo/dbmail

All these extra log details - stored in the database - is
this going to 
grow out of control? Would this table be periodically
flushed so that it 
wouldn't end up being bigger than is manageable.

As it is our mail server is logging 30-40 lines per second
during peak 
usage. I don't mind this going to a logfile but inserting
this into the 
database is going to make performance suffer unless I put
the table on a 
different disk. It makes no sense to me that for a simple
read on the 
database - e.g. check for mail - needs to correspond with a
write to the 
database for no reason except for statistics that I might
read on the 
rare occasion.

At least if the code is written for this please make a
switch in the 
database so that we can turn it off.

Sorry for the pessimistic view, just I want to have our
servers at peak 
performance.

Josh.
>> On Thu, 2007-09-06 at 09:59 +0200, Michael Monnerie
wrote:
>>>
>>> I'd also like a field messages_transferred,
mostly for pop, but also 
>>> possible for imap I guess. 
>>
>> For IMAP it might be nice to know both messages
retrieved (or I guess
>> message parts, as you don't have to retrieve the
whole thing, do you?)
>> and messages APPENDed separately.  Probably even
byte counters for
>> up/down would be useful there.

_______________________________________________
DBmail mailing list
DBmaildbmail.org
htt
ps://mailman.fastxs.nl/mailman/listinfo/dbmail

On Dienstag, 11. September 2007 01:28 Josh Marshall wrote:
> At least if the code is written for this please make a
switch in the
> database so that we can turn it off.

Of course that should be, and I even suggest doing this by
default.
But I'd like to have that, at least for a month, so that at
start of 
month we can do some nice stats and then drop all logs to a
text file, 
should it be needed later.

mfg zmi
-- 
// Michael Monnerie, Ing.BSc    -----      http://it-management.at
// Tel: 0676/846 914 666                     
.network.your.ideas.
// PGP Key:         "curl -s http://zmi.at/zmi.asc | gpg
--import"
// Fingerprint: EA39 8918 EDFF 0A68 ACFB  11B7 BA2D 060F
1C6F E6B0
// Keyserver: www.keyserver.net                   Key-ID:
1C6FE6B0

_______________________________________________
DBmail mailing list
DBmaildbmail.org
htt
ps://mailman.fastxs.nl/mailman/listinfo/dbmail

You're right Josh,
But meanwhile the log table is very usable, having this on a
raw file is not
good also.
So the switch to turn on/off saves your life, and I'm sure
that when it'll
be implemented the switch will appear in dbmail.conf.



-----Original Message-----
From: dbmail-bouncesdbmail.org [mailto:dbmail-bouncesdbmail.org] On Behalf
Of Josh Marshall
Sent: terça-feira, 11 de Setembro de 2007 0:29
To: DBMail mailinglist
Subject: Re: [Dbmail] Log table

All these extra log details - stored in the database - is
this going to 
grow out of control? Would this table be periodically
flushed so that it 
wouldn't end up being bigger than is manageable.

As it is our mail server is logging 30-40 lines per second
during peak 
usage. I don't mind this going to a logfile but inserting
this into the 
database is going to make performance suffer unless I put
the table on a 
different disk. It makes no sense to me that for a simple
read on the 
database - e.g. check for mail - needs to correspond with a
write to the 
database for no reason except for statistics that I might
read on the 
rare occasion.

At least if the code is written for this please make a
switch in the 
database so that we can turn it off.

Sorry for the pessimistic view, just I want to have our
servers at peak 
performance.

Josh.
>> On Thu, 2007-09-06 at 09:59 +0200, Michael Monnerie
wrote:
>>>
>>> I'd also like a field messages_transferred,
mostly for pop, but also 
>>> possible for imap I guess. 
>>
>> For IMAP it might be nice to know both messages
retrieved (or I guess
>> message parts, as you don't have to retrieve the
whole thing, do you?)
>> and messages APPENDed separately.  Probably even
byte counters for
>> up/down would be useful there.

_______________________________________________
DBmail mailing list
DBmaildbmail.org
htt
ps://mailman.fastxs.nl/mailman/listinfo/dbmail

_______________________________________________
DBmail mailing list
DBmaildbmail.org
htt
ps://mailman.fastxs.nl/mailman/listinfo/dbmail