[Dovecot] logfile consistency
We do some routine logfile (syslog) gathering and analysis. I've been
looking at extending this to parse the syslog output of dovecot. Hmmm...
Ignoring the leading 'date hostname' prefix, some sample lines are:
dovecot: imap-login: Login: user=, method=PLAIN, rip=dd.dd.dd.dd,
lip=dd.dd.dd.dd
dovecot: IMAP(uu): Disconnected: Logged out
dovecot: IMAP(uu): Disconnected in IDLE
dovecot: imap-login: Aborted login: rip=dd.dd.dd.dd, lip=dd.dd.dd.dd
dovecot: pop3-login: Login: user=, method=PLAIN, rip=dd.dd.dd.dd1,
lip=dd.dd.dd.dd
dovecot: POP3(uu): Disconnected: Logged out top=0/0, retr=0/0, del=0/8,
size=194970
dovecot: pop3-login: Aborted login: rip=dd.dd.dd.dd, lip=dd.dd.dd.dd
deliver(uu): msgid=<[EMAIL PROTECTED]>: saved mail to INBOX
I've obfuscated some of the local detail:
uuu represents a username/identifier;
dd.dd.dd.dd represents an IP address.
Would it be possible, please, to consider improving the consistency of the
logging information?
For instance:
1. All lines, including the "deliver", to begin "dovecot:";
2. The "IMAP(): Disconnected" to become "imap: disconnected user=";
Overall this would make it more consistently amenable to perl-like pattern
processing, at least with a reasonably hierarchical structure to the
messages. Perhaps something like:
dovecot: subprogram: event, key1=value1, key2=value2 ...
where:
"subprogram" is "{imap,pop,deliver,...}";
"event" is "{login,disconnected, ...};
and one of the "key=value" will usually be "user=".
That would really make post-processing of logging information (whether
offline, or 'live' via piped syslog) considerably easier.
Thanks.
--
: David LeeI.T. Service :
: Senior Systems ProgrammerComputer Centre :
: UNIX Team Leader Durham University :
: South Road:
: http://www.dur.ac.uk/t.d.lee/Durham DH1 3LE:
: Phone: +44 191 334 2752 U.K. :
Re: [Dovecot] v1.1 plans
Firstly, congratutulations on the official 1.0; we are now running this in production. On Tue, 17 Apr 2007, Timo Sirainen wrote: > I'm hoping to release the first alphas/betas in 2-3 months, with v1.1.0 > maybe even as early as next summer. [...] Quick check: Is "next summer" envisaged as 2007 or 2008? > Features that I'm planning on implementing: > > - Fully supported shared mailboxes and IMAP ACL extension > - Replace Squat FTS indexes with my new design > - Case-insensitive searches with non-ASCII text as well > - Maybe add support for all kinds of IMAP extensions that can be easily > supported. LEMONADE extensions especially: CONDSTORE, CATENATE and maybe > even URLAUTH if I can figure out how it should work. Could I put in a request for the "logfile consistency" item mentioned on April 3rd (and receiving some support)? See: http://www.dovecot.org/list/dovecot/2007-April/021532.html and subsequent thread. Many thanks. -- : David LeeI.T. Service : : Senior Systems ProgrammerComputer Centre : : UNIX Team Leader Durham University : : South Road: : http://www.dur.ac.uk/t.d.lee/Durham DH1 3LE: : Phone: +44 191 334 2752 U.K. :
[Dovecot] simultaneous access to folder
We have for many years been a UW-IMAP site, with users having their own traditional, private, mbox-format INBOX and folders: almost (but not quite) no complications of shared or simultaneous access. We have just completed a transparent transition to dovecot (official 1.0.0 release). But we have one residual issue affecting one important user account. UW-IMAP specifically only allows single access to "mbox" folders. If different IMAP connections are attempted to such a folder, the latest attempt kills off earlier connections. (That's just the way it works, which was mostly fine for us.) On this particular account we had explicitly set two folders to UW-IMAP's different "mbx" format, so that a group of staff could simultaneously access that folder and delete messages. This is by a single, common, id/pw account. But dovecot doesn't support "mbx" format. Is there a way for us to set up such a group-access folder under dovecot? I've checked wiki pages such as "http://wiki.dovecot.org/SharedMailboxes"; but that doesn't seem to be clear on the particular matter of which formats are suitable for such simultaneous access. It talks about different users accessing a folder; in our case it is multiple instances of the the same user. Under dovecot, can we simply let it be "mbox" format? And can dovecot (unlike UW-IMAP) then handle the simultaneous access? [Background: this is just two folders (amongst many) on one username; the overall service successfully handles over 15,000 usernames. And the solution (work-around) will only need to last a few months until that whole account is Exchange-ified (but let's not digress...!)] If I've missed something on the wiki which addresses this matter, point me in the right direction... -- : David LeeI.T. Service : : Senior Systems ProgrammerComputer Centre : : UNIX Team Leader Durham University : : South Road: : http://www.dur.ac.uk/t.d.lee/Durham DH1 3LE: : Phone: +44 191 334 2752 U.K. :
Re: [Dovecot] Quota handling - v2 - updated FR
Charles wrote: > Because it hasn't - they can't GET this mail until they deal with their > over-quota condition. All this does is prevent mail from being REJECTED, > and provide a more consistent and effective way to communicate the > problem to the user. > > [...] - but I have a customer who wants to ACCEPT > the mail for delivery (ie, never, ever REJECT a message due to > over-quota), but just not give it to the USER until they fix their quota > problem. For some environments, such as companies, universities, etc. this "accept but don't yet deliver" option is a good one. Indeed, if the incoming email is for a legal requirement (in UK, Freedom of Information, Data Protection, etc.) for that institution, then rejection/bounce simply because of a temporary quota glitch could be bad practice, bad for corporate image, and possibly even get legal if it were routine rather than one-off glitch. For other environments, presumably some that Kenny had in mind, a single level is probably fine. (But see below.) Different customer (or user community) environments may well have different preferences or requirements. Charles's "accept but don't yet deliver" sounds like a good option to have available. Kenny's simpler "deliver or reject" may well be a reasonable option for his environment. This difference really lies in their human environments, not the teechnical options or implementations. I know it's fashionable to knock and criticise Microsoft Exchange(!) but they have a multi-threshold quota system available. (One of the other thresholds is "you can't send outgoing until you get within quota" which is less easy to translate into a dovecot, IMAP-only, environment.) Perhaps (dare I say?!) MS have good reasons for making multi-threshold quotas available as an option. Kenny wrote: > option 1: if you go over quota you will not get any more mail > option 2: If you go over your quota you will get your mail your mail > will fall into a bucket nobody can see, but you will get status messages > that messages are in this bucket, with detailed instructions to follow, > which no matter how well they are written will generate more questions. Yes. Two options. Your environment may suit the first, simpler, option. Fine. Charles (and some of the rest of us) would assess our different environments as being able to benefit from the second being available in some circumstances. Kenny continued: > A hard bounce is the right way to go in this case, because it will let > the sender know right away that there is a problem sending to the user. For some environments (e.g. users at a mass-market ISP) this may well be appropriate. For other environments (e.g. the financial/legal department within that same ISP) that probably is far from ideal. In ITIL terms: two different (and necessarily different) Service Level Agreements (SLAs) for two different customer groups, whose implementation could be greatly eased by the availability of a multi-threshold quota option (perhaps used for one group, not the other). Hope that helps. -- : David LeeI.T. Service : : Senior Systems ProgrammerComputer Centre : : UNIX Team Leader Durham University : : South Road: : http://www.dur.ac.uk/t.d.lee/Durham DH1 3LE: : Phone: +44 191 334 2752 U.K. :
Re: [Dovecot] 1.0.1 release candidate 2
On Mon, 11 Jun 2007, Timo Sirainen wrote: > I'll release v1.0.1 in a day or two, but it would be nice to get some > testing before the release to see if I managed to break something after > the Mercurial conversion. And did I forget something that should be > fixed for v1.0.1? > > http://dovecot.org/tmp/dovecot-1.0.1rc2.tar.gz > > Changes since v1.0.0: > > [...] On a couple of occasions we discussed having the logfile entries be somewhat more consistent and more easily machine-parseable. And I think I saw mention of a potential mail_log plugin or similar. Was that related? Is this likely to be in 1.0.1? If this were planned, I would hope to try to test it for you. -- : David LeeI.T. Service : : Senior Systems ProgrammerComputer Centre : : UNIX Team Leader Durham University : : South Road: : http://www.dur.ac.uk/t.d.lee/Durham DH1 3LE: : Phone: +44 191 334 2752 U.K. :
