This will only affect, if it is really going to affect anything, who'll have this option enabled.
I really don't thing from my experience with *SQL, that a simple insert will affect anything, if so, the "last_login" field that exists in "dbmail_user" table, that is updated every time a user logs in, this is affecting the system also. I do not agree with you guys, even that we stay with a log table with 100.000 records, is from the sys admin to take care of this data, and prepare the server with the proper hardware to have this (disk size, memory). How long does it take to update the "last_login" field? 0.005 secs? How long will take to insert a record in the log table, and in the log table for the received messages? 0.01 secs? Even that it was 1 sec, that I don't belive it'll take that long, even imaging that in a really stressed server, with 500 simultanious logins this'll happen. A server with that kind of simultaneous logins will not be a P4 3.0GHZ with HT and 1GB of RAM for sure. You guys sorry me, but don't agree and don't belive that'll delay anything in the mail system. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Vladimir Likhachev Sent: quarta-feira, 12 de Setembro de 2007 9:29 To: DBMail mailinglist Subject: RE: [Dbmail] Log table (Common opinion - my own only) This type of logging (client's actions detailed check with any aim), i think, is a (possible) part of system admin (company owner) policy, not of MDA/MTA. The next step of such logging is "which SIEVE rule put this message into this folder", ... Isn't end point on this way. Some SPECIAL commercial MTA/MDA exists (Taxcom in Russia, for example), which confirmed each (important) stage of message transmission - receive by MTA, put into mailbox, user read, user (maybe, extern program) processing - and sends signed confirmations to sender and/or admin after each step. If such functionality required, common purpose MTA/MDA is unusable. At first, DBMAIL was simple, fast (even on really large mailboxes), effective and suitable MDA with a lot of SQL storage based advantages (backup, etc...). Now, after DBMAIL_LMTP and SIEVE implementations, it becomes more complicated, required more resources, and its stability may be broken by users writing its own SIEVE scripts. Please, don't make "sendmail number 2" from this realy excellent product. Best regards Vladimir Forgive my poor English, please... _____ > Subject: RE: [Dbmail] Log table > From: [EMAIL PROTECTED] > To: [email protected] > Date: Tue, 11 Sep 2007 08:21:47 -0600 > > On Tue, 2007-09-11 at 09:16 +0100, Jorge Bastos wrote: > > 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 > > If implemented, perhaps it could be enabled/disabled for a subset rather > than the whole userbase? Eg. enable it for specific clientid's, or for > specific users only. > > -- > Jesse Norell > Kentec Communications, Inc. > [EMAIL PROTECTED] > _______________________________________________ > DBmail mailing list > [email protected] > https://mailman.fastxs.nl/mailman/listinfo/dbmail _____ Connect to the next generation of MSN Messenger Get it now! <http://imagine-msn.com/messenger/launch80/default.aspx?locale=en-us&source= wlmailtagline>
_______________________________________________ DBmail mailing list [email protected] https://mailman.fastxs.nl/mailman/listinfo/dbmail
