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.h...@gmail.com>
