Re: [Dovecot] Disable maildir indexing and dovecot-uidlist on LMTP/LDA delivery
Jouko Nikula <jonikula@gmail.com> writes:
Is there a way to use LMTP (or LDA) so that maildir index and dovecot-uidlist are not updated?
My setup is such that mail delivery sees user's maildir as write only. This setup works well when using postfix for mail delivery, but when I try to switch to dovecot LMTP the lmtp process wants to read the dovecot-uidlist and fails on insufficient privileges. Is there a way around this without exposing the maildir and mail home for read access?
You could create MEMORY indices e.g.
mail_location = maildir:~/Maildir:INDEX=MEMORYwhich will allow all the other processing like sieve to work.
However, I would look at the cause of the "insufficient privileges": it is a symptom of something that could lead to other problems.
Joseph Tam <jtam.home@gmail.com>
On Thu, Apr 3, 2014 at 1:36 AM, Joseph Tam <jtam.home@gmail.com> wrote:
Jouko Nikula <jonikula@gmail.com> writes:
Is there a way to use LMTP (or LDA) so that maildir index and dovecot-uidlist are not updated?
My setup is such that mail delivery sees user's maildir as write only. This setup works well when using postfix for mail delivery, but when I try to switch to dovecot LMTP the lmtp process wants to read the dovecot-uidlist and fails on insufficient privileges. Is there a way around this without exposing the maildir and mail home for read access?
You could create MEMORY indices e.g.
mail_location = maildir:~/Maildir:INDEX=MEMORYwhich will allow all the other processing like sieve to work.
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? 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.
However, I would look at the cause of the "insufficient privileges": it is a symptom of something that could lead to other problems.
Joseph Tam <jtam.home@gmail.com>
The cause is that I have not given lmtp read access to mail/home dir. :-) So this is intentional.
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>
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>
Now in my configuration LMTP does not have read access to the mailboxes. So it can only read the CONTROL files and write all files. In my opinion this means added security.
And thanks a lot to everyone for your help!
participants (2)
-
Joseph Tam
-
Jouko Nikula