- dovecot - dovecot.org

[Dovecot] Re: Timezone of logentries from dovecot (Timo Sirainen)
by Lars Skovgaard 04 May '04

04 May '04

On Thu, 2004-04-29 at 15:57, Timo Sirainen wrote: > One more reason to make all logging go through dovecot-master process.. > > Temporary fix of course is setting login_chroot = no to config file. Thanks, Timo, that did the trick. Also thanks to Quentin for his reply, though I don't understand any of it. As stated, my knowledge of unix is rather limited... On Thu, 2004-04-29 at 15:48, Quentin Garnier wrote: > It's because the logging process is chrooted, doesn't have TZ env. var. > set, and doesn't have a correct /etc/localtime (or whatever your libc > uses) _inside_ the chroot directory. Therefore its timezone is the > default, UTC (formerly known as GMT). As I understand it, it would be a good idea to come up with a more permanent fix. However, I have no idea where to begin. Timo writes about making all logging go through the dovecot-master process – can anyone point me in the direction of information on how to accomplish this? Quentin writes about TZ env. var. (TimeZone?), /etc/localtime and the chroot directory. I'm sorry, Quentin, but I need a bit more info. I have the correct /etc/localtime, as far as I can tell. I've tried looking up TZ env. var. in my man-pages, but haven't come up with anything. I'll copy my /etc/localtime to the login_dir and see if this is enough. Thanks again, guys! /Lars

2 1

[Dovecot] Envelope From changed - why?
by Tom Alsberg 04 May '04

04 May '04

Hi there. I am evaluating Dovecot as an IMAP server. I noticed on thing which irritates me. When a user saves a message to an IMAP folder with the Dovecot server, the envelope From line is changed to the address of that user, instead of keeping the From line of the original message. How can I have the original envelope From line preserved when saving messages? -- Tom -- Tom Alsberg - certified insane, complete illiterate. Homepage: http://www.cs.huji.ac.il/~alsbergt/ * An idea is not responsible for the people who believe in it.

5 18

[Dovecot] Maildir files in cur without info
by Christoph Hohmann 04 May '04

04 May '04

Hi, I have tried to use the same Maildir dovecot uses with another program and encountered the problem that Dovecot seems to move files from new to cur in maildir-sync.c::maildir_scan_dir without adding an info part. On the page http://cr.yp.to/proto/maildir.html is written that mails have to be renamed to uniq:info when moved to the cur directory. Could this be a bug in dovecot? -- http://reboot.animeirc.de http://sylpheed-claws.sourceforge.net/

3 3

[Dovecot] 1.0-test4
by Timo Sirainen 03 May '04

03 May '04

http://dovecot.org/test/ Maildir syncing should be pretty optimized now. And it works now with more than 40 messages in mailbox :)

1 0

[Dovecot] Dovecot hangs after 2 or 3 days
by Jens Gutzeit 03 May '04

03 May '04

Hi all, We've some problems with our dovecot installation, its the latest stable compiled on a debian woody box. After 2 or 3 days dovecot hangs, no user can login (pop3 and imap), there's nothing in the logs. The client does allways timeout, if I restart dovecot all works well again. It's a box with s.th. around 400 users, we've enough mem free, load is not a problem, it went from 0.9 to 0.1 after migrating from cyrus-imapd, so this doesn't seem to be hardware related. My dovecot conf is online at: http://mail.sunday.de/dovecot.conf best regards/Mit freundlichen Grüßen Jens Gutzeit -- Tel.: +492151 652945 Ein PC besteht sowieso i.d.R. zu 90% aus faulen Kompromissen, zu 7% aus Elektronikschrott und zu 3% aus wirren Ideen. Benedict Mangelsdorff

1 0

[Dovecot] 1.0-test1 released
by Timo Sirainen 03 May '04

03 May '04

http://dovecot.org/test/ I couldn't break this with Evolution with a few minutes of testing, so here's the first tarball release based on the new indexing code. Try if you're interested, but don't try it on any real mailboxes, or at least keep backups :) Also note that dovecot-uidlist file format has changed a bit, Dovecot 0.99.x isn't able to read it anymore. Things to do: - mbox code doesn't even compile, so it's disabled - custom flags aren't implemented - recent flags are broken - cache file handling isn't working now, so it's disabled - maildir syncing code isn't as well optimized as it used to be - NFS-safety to indexes (pretty easy)

3 7

[Dovecot] 1.0-test2 released
by Timo Sirainen 03 May '04

03 May '04

http://dovecot.org/test/ I still haven't done much real world testing, but I've been thinking about all the potential race conditions a lot since last time and fixed a lot of them. There might still be some.. Changes since -test1: - Locking fixes - A lot more difficult to crash it with corrupted index files - Recent flag works, this time exactly as IMAP RFC says - Maildir syncing fixes - fcntl_lock_disable and mmap_disable settings to make it work with NFS.. almost. Not very well tested and there's a few performance issues left. - mmap_no_write setting to disable mixing write/mmap calls. Required for OpenBSD. Uses slightly more memory. If you can break the indexes, I'd like to know about that. I think they should work pretty well now.

2 1

[Dovecot] Timezone of logentries from dovecot
by Lars Skovgaard 29 Apr '04

29 Apr '04

Hi I've been using dovecot for a long time now, and have nothing but praise for it. It's considerably faster than uw-imap, and has been very easy to configure, in spite of my limited knowledge of unix. One thing still botheres me, though, and that's the time of the entries in my logfiles. It seems that dovecot logs it's entries in GMT, while I'm using GMT+1. This is made even worse by the fact that we're now using daylight savings time, which upps the difference to two hours. Here's a couple of lines from my logs to show the difference: Apr 29 14:30:07 misterp mach_kernel: ipfw: 10000 Deny UDP 213.122.19.185:33123 129.142.126.35:137 in via en0 Apr 29 14:30:59 misterp mach_kernel: ipfw: 4000 Accept TCP 80.197.22.210:38518 129.142.126.35:995 in via en0 Apr 29 12:30:59 misterp pop3-login: Login: torben [80.197.22.210] Apr 29 14:32:25 misterp mach_kernel: ipfw: 10000 Deny UDP 195.122.208.191:1066 129.142.126.35:1434 in via en0 I don't know how to fix this, whether it's in dovecot or somewhere in a system-setting. However, all other applications log their entries with the systems current setting, so I suspect it's in dovecot. I would very much appreciate any help on the subject. Btw, I'm using MacOS X 10.2 with dovecot 0.99.10.4. Thanks! /Lars

3 2

[Dovecot] Index abuse
by Rick Jones 28 Apr '04

28 Apr '04

How resilient is Dovecot's indexing mechanism? (seeing as it's been extensively re-vamped I guess this question may have different answers for 0.99 & 1.0). To put it in context, I'm playing with server-side automatic maintenance scripts for things like deleting messages more than x days old from folders a, b, c, etc. (using Maildir layout). So far I'm just zapping files in the cur and new directories and nothing amiss appears to happen from the IMAP client's viewpoint. I just wonder if I'm storing up trouble. Will the index files continue to hold references to non-existent files and get bloated, or do they self-clean? -- Rick Jones

3 3

[Dovecot] Feature request: more log info/stats
by Christian Balzer 27 Apr '04

27 Apr '04

Hello, even though Timo seems to be hibernating (it's not _that_ cold in ole Suomi ;) I'd like to beg for a feature that would be very much appreciated over here. If something like this is already present and eluded my thorough archive and doc searches, feel free to smack me and then point me to the right direction. Feature request: More extensive session information and statistics in the logs. Currently all I can get from dovecot is login information, there's not even a log entry when a session was ended either by the client or a timeout. In addition a short summary would be be very helpful, qpoppers one liner stats come to mind like this: --- Apr 12 05:30:30 test in.qpopper[21266]: Stats: test 6 21868 2 108126 some.do.main IP.AD.DR.ES [pop_updt.c:296] --- Stating that user test downloaded/deleted 6 mails with 21868 bytes total and kept 2 in the inbox. This might be expanded on for IMAP operations like moves or such and raw data about transferred bytes in/out added (in my case I get that info from perdition), but the really important parts are: When did a user log into the server, when did that session end? How many new mails were read and how many mails deleted during that session? The rationale is that with this info at hand the (unfortunately) very common user whining along the lines of "the mail server ate my mails" or "I never saw this mail!" are much easier to refute. Regards and keep up the good work, Christian Balzer -- Christian Balzer Network/Systems Engineer NOC chibi(a)gol.com Global OnLine Japan/Fusion Network Services http://www.gol.com/

5 6