- dovecot - dovecot.org

[Dovecot] default_mail_env auto-detect woes for maildir users
by David Friedlander 05 Feb '06

05 Feb '06

Hello-- I am a fairly new dovecot user and have run into a problem. I am running dovecot 1.0alpha5 (built from source) on a Fedora Core 1 machine. The system has about 400 users with over 80 IMAP users, and we have just transitioned from UW-IMAP. Thus all users are currently still mbox users. I would like to transition them to maildir users (this was the main point for me switching servers), and I chose dovecot because it could simultaneously support both formats. My dovecot.conf uses auto_detect (no default_mail_env defined, by choice). Auto-detect is working fine for mbox users, as shown by this (edited) log snippet: dovecot: imap(janeuser): maildir: couldn't find root dir dovecot: imap(janeuser): mbox: root exists (/Home/janeuser/mail) dovecot: imap(janeuser): mbox: INBOX exists (/var/mail/janeuser) dovecot: imap(janeuser): mbox: root=/Home/janeuser/mail, index=/Home/janeuser/mail, inbox=/var/mail/janeuser However, for another user who already has ~/Maildir and a proper maildir-format spool location ( /var/mail/joeuser/{cur|new|tmp} ) the log shows: dovecot: imap(joeuser): maildir: root exists (/Home/joeuser/Maildir) dovecot: imap(joeuser): maildir: root=/Home/joeuser/Maildir, index=/Home/joeuser/Maildir, control=, inbox= (Mail clients show no messages, but one can see them from the UNIX shell and with mutt on the server.) If I set default_mail_env = maildir:~/Maildir:INBOX=/var/spool/mail/%u then everything works fine for 'joeuser'. However, I need auto-detect during this transition phase. My questions, please: * How do I get INBOX ("inbox=") to be properly defined/detected? * Must I do this with namespaces, and how does that affect the fact that there will be a transition period where some users use mbox and others use maildir? * Other advice? I have been unable to track this down so far, between reading the Dovecot documentation and Googling the dovecot mailing list archives. Thanks in advance, David

2 2

[Dovecot] Support for Kmail maildir format
by Graham Cobb 04 Feb '06

04 Feb '06

Has anyone looked into providing support in dovecot for Kmail folders? I would like to make my Kmail folders (on my main desktop system) available to my other systems (including over a VPN when I am travelling). Kmail is my main mail program and I have a lot of mail in a lot of folders, so I don't want to set up a separate IMAP service and move all the mail and folders. Kmail's use of maildir seems to folow the basic maildir approach except that sub-folders are handled differently. If you create a folder (say it is called ABC) in Kmail and start putting mail in it, Kmail creates a directory on the disk called ABC (not .ABC) and creates the cur, new and tmp folders within it to contain the email. If you then create a subfolder of ABC (say it is called DEF, contained within the ABC folder), Kmail creates a directory on the disk called .ABC.directory and creates the DEF directory within that. In other words, maildir directories are given the same name as the mail folder (with no leading dot) but sub-folders are contained in disk directories called .<folder-name>.directory. I have taken a quick look at the dovecot code and am fairly sure this could be handled by a variant on the existing maildir code (e.g. by changes to maildir_fill_readdir and other routines). Has anyone tried this? Graham

5 12

[Dovecot] rquotad (NFS) quota plugin
by Thomas Wouters 03 Feb '06

03 Feb '06

The attached patch is an updated version of my quota-rquotad patch for the quota plugin. Like quota-fs, it only does quota reporting, not enforcing or changing. It also only works on FreeBSD, and possibly other *BSD's. It lacks any and all configure-time tests to see if RPC is even supported, and hardcodes the (Free)BSD way of getting at the NFS server of an NFS mount. I'm mostly mailing it around to avoid duplicate work, in case anyone is looking for it. I do intend to generalize the plugin-patch, and add proper configure checks, I just haven't gotten around to testing it on other BSD systems. Linux support would be nice, but getting at the NFS server of an NFS mount is apparently quite a hassle, as it means reading /etc/mtab or /proc/self/mounts. Yuck. -- Thomas Wouters <thomas(a)xs4all.net> Hi! I'm a .signature virus! copy me into your .signature file to help me spread!

1 0

[Dovecot] mbox to maildir conversion on a user-by-user basis!
by Tony Kay 03 Feb '06

03 Feb '06

In the midst of evaluating Dovecot for use in solving some mbox locking issues (while also waiting for our eventual migration to maildir), I had an epiphany. It looks like Dovecot's auto-detection of mail formats would allow us to migrate from mbox to maildir on a user-by-user basis! I was thinking: 1. Let dovecot autodetect mail storage 2. Use some procmail trickery to detect which format to deliver into (I am researching how to do the detection on a user-by-user basis) 3. Manually convert users as you want by: - Temporarily disable mail delivery for that user (at least make it look like the inbox is locked) - Run conversion on mbox files -> maildir format - Put in the procmail hack for them - Re-enable delivery Way cool. I am still working out the details, but I was wondering if anyone sees a problem with this??? -- Anthony Kay University Computing Center (541) 346-1719 GPG Fingerprint: B0DB D46A 60AF FAE7 A94A 5075 0CB4 4D88 9F4F 7F09 Sanity is a cozy lie. Susan Sontag

2 1

[Dovecot] not creating homedirs when using maildir format
by Ben Halicki 03 Feb '06

03 Feb '06

Hi all, I'm in the process of setting up dovecot, but for some reason, it's not creating home directories if they don't already exist. I have the following line in dovecot.conf: default_mail_env = maildir:~/mail:INBOX=/var/mail/%u I have set permissions on /home to allow everyone full access, so creating directories in /home by dovecot non-root processes shouldn't be a problem. If I instruct dovecot to use mbox format, directories are created without a problem. The problem only seems to exist with maildir. Any help would be greatly appreciated! Thanks and regards, Ben Halicki Information Technology Officer Macquarie Textiles Group Limited Phone: +61 2 6043 0235 Fax: +61 2 6041 1321

4 3

[Dovecot] Dovecot(imap) problem
by Clovis Tristao 03 Feb '06

03 Feb '06

Feb 1 20:13:15 myhost imap(someuser): file mbox-rewrite.c: line 429 (mbox_write_header): assertion failed: (hdr_parsed_size.physical_size == hdr_size) I'm using Fedora Core 4, dovecot 0.99.14-4. Any idea? How to fix this problem? Thanks a lot, Clóvis -- Clovis Tristao - UNICAMP/Faculdade de Engenharia Agricola Administrador de Redes - Secao de Informatica (SINFO) E-mail: mailto:clovis@agr.unicamp.br http://www.agr.unicamp.br Fone(0xx19) 37881031-37881038 ou FAX(55xx19) 37881005/37881010

4 3

Re: [Dovecot] not creating homedirs when using maildir format
by Ben Halicki 02 Feb '06

02 Feb '06

"Ben Halicki" <ben.halicki at macquarietextiles.com.au> writes: > Hi all, > > I'm in the process of setting up dovecot, but for some reason, it's not > creating home directories if they don't already exist. > > I have the following line in dovecot.conf: > > default_mail_env = maildir:~/mail:INBOX=/var/mail/%u > > I have set permissions on /home to allow everyone full access, so > creating directories in /home by dovecot non-root processes shouldn't be > a problem. If I instruct dovecot to use mbox format, directories are > created without a problem. The problem only seems to exist with maildir. > > Any help would be greatly appreciated! Never done this, ISTR there is a PAM module that is supposed to do this (create the directory). It would require you to use PAM, obviously. -- Matthias Andree Thanks for the reply Matthias. Only problem with PAM and pam_mkhomedir, is that Dovecot doesn't seem to open a session, so pam isn't called and pam_mkhomedir doesn't get the chanceto create a home directory. I can't understand why this works with mbox, but not withmaildir!Thanks again,Ben HalickiInformation Technology OfficerMacquarie Textiles Group LimitedPhone: +61 2 6043 0235Fax: +61 2 6041 1321

1 0

Re: [Dovecot] Question about Dovecot and NFS
by Tony Kay 02 Feb '06

02 Feb '06

On Thu, 02 Feb 2006 11:48:02 +0200, Timo Sirainen <tss(a)iki.fi> wrote: > -- SNIP -- > As long as both hosts keep using dotlocking, Dovecot should be able to > handle the above without any corruption problems. > > > I did some testing w/dovecot 0.99 earlier in this same config, > > Forget those results and try with 1.0beta instead :) > I ran tests on 1.0b2. I could _not_ make dovecot misbehave on NFS w/two physical servers accessing the same mailbox. All of the "undesirable" things that happened (i.e. really poorly written clients suffering strange views of the mailbox due to their own stupidity) were well within IMAP spec., and are non-destructive/lossy. Kudos Timo! Thanks for writing some really excellent code. -- Anthony Kay University Computing Center (541) 346-1719 GPG Fingerprint: B0DB D46A 60AF FAE7 A94A 5075 0CB4 4D88 9F4F 7F09 The camera makes everyone a tourist in other people's reality, and eventually in one's own. Susan Sontag

1 0

[Dovecot] SRC.RPM for dovecot (cvs-2006-01-30) with lda
by Sergey Ivanov 02 Feb '06

02 Feb '06

Hi, there is dovecot.src.rpm for ALTLinux, (dovecot beta2 with sieve local delivery agent) uploaded to http://ftp.altlinux.org/pub/distributions/ALTLinux/Daedalus/SRPMS.daedalus/… -- Sergey Ivanov

1 0

Re: [Dovecot] Question about Dovecot and NFS
by Tony Kay 02 Feb '06

02 Feb '06

On Wed, 01 Feb 2006 11:45:16 +0200, Timo Sirainen <tss(a)iki.fi> wrote: > On Tue, 2006-01-31 at 22:42 -0800, Tony Kay wrote: > > How does dovecot handle this kind of conflict. I.e. how would one dovecot IMAP on server A detect that dovecot on server B had rewritten something like flags on the mailbox they are both accessing? I'm sure it doesn't leave the dot lock sitting around, since that would block mail delivery. > > It just checks if mbox's mtime has changed. If it has, it checks if > there are new mails or if it needs to do some other synchronization > (mbox_dirty_syncs / mbox_very_dirty_syncs causes it to delay it as long > as possible). > > UW-IMAP also checks if mtime has changed, but instead of trying to > figure out what changed it just disconnects the client with an > "unexpected mbox change" error. UW uses a "kiss of death" signal for collaborative locking...the mtime changes are all assumed to be appends as far as I know. The problem (which I can reproduce) comes with a situation like this: - IMAP host A and B access INBOX for the same user from different physical servers which share the inbox via NFS - Neither sees the other (because UW imap assumes lingering opens come from c-client apps, and it uses signals/flock/tmp to sync them, which are not available when A and B are on separate hosts). - Delete and expunge a message on B - 'A' can still read the expunged message. - Mark two messages for delete on A, including the one previously expunged by B - New message delivered to inbox (possibly by yet another host) - Expunge on A - New message is lost My theory is that the two IMAPs are both holding a fd open, and this causes one of the copies to become stale (in the sense it no longer has a filesystem name). The new mail is delivered to the non-stale box, and then the expunge on 'A' causes the stale open file to be "rewritten" over the top of the non-stale one. Result: mail loss. We also see things like message flags that magically reset themselves, etc. I did some testing w/dovecot 0.99 earlier in this same config, and it seems like it has some issues. For example a delete/expunge on IMAP A was "sort-of" seen by the B (fetch complained that the UIDs had changed, and would not work until a NOOP was done...this is technically OK), but B magically restored the deleted message with a new UID (which is not so good, since a client that caches stuff may now have a strange view of the world...I need to examine the set of "update" notices that went along with these events to better understand the implications). This also worries me because the "magic" reappearance indicates a copy from a stale fd, which could exhibit the same mail loss I produced w/UW IMAP. I am planning on updating to your latest source tree tomorrow (I am out of time today), and see if I can make it "lose" new mail. Opinions??? Thanks! Tony

2 1