On Thu, 3 Apr 2014, Jouko Nikula wrote:
I now used:
mail_location = maildir:~/mail:INDEX=MEMORY:CONTROL=/var/mail/%d/ctrl/%u
and for sieve:
plugin { sieve = /var/mail/%d/ctrl/%u/dovecot.sieve sieve_dir = /var/mail/%d/ctrl/%u/ }
I also have two dovecot instances. One is responsible for imap/pop3 and other is responsible for sasl and and lmtp. The latter uses configuration above and the former differs on the mail location so that it does not have the INDEX=MEMORY setting:
mail_location = maildir:~/mail:CONTROL=/var/mail/%d/ctrl/%u
Do you see problems in this setup?
No, but I don't use sieve (nor INDEX=MEMORY for that matter), so my knowledge is limited here.
My understanding is that now I'm wasting little bit CPU on creating indices for new mail, but I nevertheless have working and stored indices on the dovecot's imap instance.
I/O is more precious than CPU, and that's what indices tries to conserve. I don't know how much performance degradation append operations (i.e. new mail) has on index updates, but it's probably proportional to mailbox size.
If your mailboxes are small, it's probably negligible.
However, I would look at the cause of the "insufficient privileges": it is a symptom of something that could lead to other problems.
The cause is that I have not given lmtp read access to mail/home dir. :-) So this is intentional.
That is bizarre -- I can't think of how you can profit from denying read access to indices, but allow write access, and also allow read access to the mailboxes.
Joseph Tam <jtam.home@gmail.com>