It may be other aspect of detailed users activity logging - law aspect. Users
mail activity details (count of mail checks, messages/bytes obtained, etc) is
(may be treated as) a part of personal user's data, useful for different
purposes. No problem for company (internal mail), but a problem for public mail
system in some countries.
All required information (in case of using POP3 and non-plaintext auth)
presents in syslog
cat /var/log/mail/errors | head -n 1000
Sep 9 05:06:53 sorm dbmail/pop3d[27096]: serverchild.c,PerformChildTask:
incoming connection from [192.168.0.135]Sep 9 05:06:53 sorm
dbmail/pop3d[27096]: authsql.c,auth_md5_validate: user [novikov] is validated
using APOPSep 9 05:06:53 sorm dbmail/pop3d[27096]: pop3(): user novikov logged
in [messages=95, octets=893176]
....Sep 9 05:07:14 sorm dbmail/pop3d[27096]: pop3_handle_connection(): user
novikov logging out [messages=0, octets=0]....
Sep 9 05:07:48 sorm dbmail/pop3d[30585]: serverchild.c,PerformChildTask:
incoming connection from [192.168.0.135]Sep 9 05:07:48 sorm
dbmail/pop3d[30585]: authsql.c,auth_md5_validate: user [novikov] is validated
using APOPSep 9 05:07:48 sorm dbmail/pop3d[30585]: pop3(): user novikov logged
in [messages=0, octets=0].....
Sep 9 05:07:48 sorm dbmail/pop3d[30585]: pop3_handle_connection(): user
novikov logging out [messages=0, octets=0]....
Sep 9 05:08:48 sorm dbmail/pop3d[30443]: serverchild.c,PerformChildTask:
incoming connection from [192.168.0.135]Sep 9 05:08:48 sorm
dbmail/pop3d[30443]: authsql.c,auth_md5_validate: user [novikov] is validated
using APOPSep 9 05:08:48 sorm dbmail/pop3d[30443]: pop3(): user novikov logged
in [messages=0, octets=0]....
Sep 9 05:08:48 sorm dbmail/pop3d[30443]: pop3_handle_connection(): user
novikov logging out [messages=0, octets=0]....
Sep 9 05:09:48 sorm dbmail/pop3d[31089]: serverchild.c,PerformChildTask:
incoming connection from [192.168.0.135]Sep 9 05:09:48 sorm
dbmail/pop3d[31089]: authsql.c,auth_md5_validate: user [novikov] is validated
using APOPSep 9 05:09:48 sorm dbmail/pop3d[31089]: pop3(): user novikov logged
in [messages=0, octets=0]....
Sep 9 05:09:48 sorm dbmail/pop3d[31089]: pop3_handle_connection(): user
novikov logging out [messages=0, octets=0]
loglevel in dbmail.conf = 2
syslog - by default
cat /etc/syslog.conf
....
# Mail loggingmail.=debug;mail.=info;mail.=notice
-/var/log/mail/infomail.=warn
-/var/log/mail/warningsmail.err
-/var/log/mail/errors....
Linux Mandriva 2006.
All the time i'm using APOP POP3 auth and SMTP auth, so can't show real logs
for other variants, but common Unix knowledge says - all required syslog
information presents in each auth and delivery variant.
Reasons for create double log system - really unknown...
Best regards
Vladimir
> From: [EMAIL PROTECTED]> To: [email protected]> Subject: Re: [Dbmail] Log
> table> Date: Fri, 14 Sep 2007 00:01:50 +0100> > Guys guys, nobody else talk?
> :PP> (it's just to test that the mailling list is not dead again sinse it was
> > quiet today)> > Jorge> > ----- Original Message ----- > From: "Jorge
> Bastos" <[EMAIL PROTECTED]>> To: "'DBMail mailinglist'" <[email protected]>>
> Sent: Thursday, September 13, 2007 9:46 AM> Subject: RE: [Dbmail] Log table>
> > > >I agree Josh with some parts you wrote,> > These log tables, are two
> different things, one for login/logout for> > pop3/imap for statistics, and
> the 2nd for the delivered messages.> > So having the possibility to have this
> "subsystem" where the sys admin can> > chose, to enable/disable it, and if
> enable to chose to write to a> > text/xml/ascii with separated with ";" file,
> or MySQL/PostGreSQL/SQLite, > > and> > when writing to one of the *SQL
> systems have the chance to define the> > "host/user/pwd/database", so that
> can improve performance for things like > > in> > your case, the admin
> choses, or in the same server/database, or in > > another,> > and then the
> admin makes the server performance.> > I have on the wiki this two ideas for
> 2.3x, with this discursion, we could> > write all something like a final
> statement that fits for all (like Aaron> > said) and then rearrange the
> things on this two pages.> > My Sugestion is to start writing it here on the
> list emails and when> > everybody approves it, including Paul and Aaron of
> course, let's put the> > final results there.> > People for who this king of
> function doesn't matter or don't want they > > have> > their problem resolved
> since this will have an on/off parameter.> >> >
> http://dbmail.org/dokuwiki/doku.php?id=mail_trafic> >> >
> http://dbmail.org/dokuwiki/doku.php?id=log_conn> >> >> > Jorge> >> >> >> >
> -----Original Message-----> > From: [EMAIL PROTECTED] [mailto:[EMAIL
> PROTECTED] On > > Behalf> > Of Aaron Stone> > Sent: quinta-feira, 13 de
> Setembro de 2007 5:05> > To: DBMail mailinglist> > Subject: Re: [Dbmail] Log
> table> >> > This has been a great thread. I've read everything. I had been on
> the> > side of a logging table, and I do think that this may be important,
> but> > there have been excellent arguments for much, much more flexible
> hooks> > to other reporting formats that I hadn't thought of at all.> >> > I
> suspect a lot of this discussion will end once there's some good code> > for
> us all to use, but until then, keep the ideas rolling (and let's> > wiki some
> of these proposals, too!).> >> > Aaron> >> > On Thu, 2007-09-13 at 08:14
> +1000, Josh Marshall wrote:> >> Hi All,> >>> >> I'm actually happy that my
> small protest generated a lot of discussion> >> (I don't want to call it
> arguments) - it has pointed out that one> >> person's idea might not fit all,
> but at least with a number of differing> >> opinions it is easier to make a
> decision on the best option.> >>> >> My mail log is over 300Mb per day. I
> have three mail servers connecting> >> to a MySQL server that is fault
> tolerant thanks to heartbeat and drbd.> >> My bottleneck is the MySQL server.
> By adding these logs to the MySQL> >> server I believe my customers are going
> to suffer performance issues,> >> whether it be due to the constant inserts
> (remember inserts are more> >> costly than updates) or due to the increase of
> data space on the server.> >> There have been suggestions in this thread that
> we log more data to the> >> database than is currently going to the logfile,
> so my 300Mb per day> >> could increase to maybe 1Gb depending on the level of
> data going in for> >> statistics.> >>> >> I really do like the idea of a
> plugin for the statistics, so that I can> >> choose to log these to a file,
> to a mysql or postgres database. If I can> >> send these to a different mysql
> database then I am less concerned about> >> it being a performance issue
> (especially if the inserts were set to not> >> wait for the database to
> complete the transaction). If the fields and> >> operations that were logged
> were able to be selected in a fine-grain> >> manner then we could all get the
> data we require. As long as this> >> doesn't take a lot of development effort
> and doesn't have the potential> >> to introduce a lot of new bugs then I see
> this as an improvement to the> >> software that would be useful to
> administrators of smaller installations.> >>> >> Please don't get me wrong, I
> do get annoyed at being asked to wade> >> through 2 million log lines to find
> out information for a customer, and> >> I do think that the statistics in
> dbmail would be useful for some. But> >> it is still not going to contain all
> the information one needs,> >> especially since a lot of the questions are
> "why was my message bounced"> >> or "did this message get delivered
> externally" which in my case is> >> Postfix's job, and they don't log to the
> same database. So I have to go> >> to the logfiles anyway, or run a log
> watcher that places data into a> >> mysql table for me.> >>> >> Regards,> >>
> Josh.> >>> >> Paul J Stevens wrote:> >> >> >> > I kind of agree with Vladimir
> and Josh: though I understand the> >> > usefulness of wiz-bang usage
> statistics I don't see stuffing all that> >> > information in the dbmail
> database as good design.> >>> >>
> _______________________________________________> >> DBmail mailing list> >>
> [email protected]> >> https://mailman.fastxs.nl/mailman/listinfo/dbmail> >> >
> _______________________________________________> > DBmail mailing list> >
> [email protected]> > https://mailman.fastxs.nl/mailman/listinfo/dbmail> >> >
> _______________________________________________> > DBmail mailing list> >
> [email protected]> > https://mailman.fastxs.nl/mailman/listinfo/dbmail> > > >
> _______________________________________________> DBmail mailing list>
> [email protected]> https://mailman.fastxs.nl/mailman/listinfo/dbmail
_________________________________________________________________
News, entertainment and everything you care about at Live.com. Get it now!
http://www.live.com/getstarted.aspx
_______________________________________________
DBmail mailing list
[email protected]
https://mailman.fastxs.nl/mailman/listinfo/dbmail
