Hello, just to soothe my paranoia from many years of qpopper usage, which enforces solitary access to a POP mailbox. Only one login per user is possible at the same time and if a session terminates w/o qpopper being properly notified it will remain locked for some time, 30 minutes by default. With dovecot (0.99.10.4) one can login multiple times (using POP, with IMAP of course this comes as no surprise :) and thus I presume this bit from the configuration: --- # Should we create dotlock file even when we want only a read-lock? Setting # this to yes hurts the performance when the mailbox is accessed simultaneously # by multiple processes, but it's needed for reliable reading if no other # locking methods are available. #mbox_read_dotlock = no --- means that if the only other reading accesses to a (mbox style in this case here) mailbox are via other dovecot processes everything will be fine? Regards, Christian Balzer -- Christian Balzer Network/Systems Engineer NOC chibi at gol.com Global OnLine Japan/Fusion Network Services http://www.gol.com/
* Christian Balzer <chibi at gol.com> (20040518 21:10):> presume this bit from the configuration: > --- > # Should we create dotlock file even when we want only a read-lock? Setting > # this to yes hurts the performance when the mailbox is accessed simultaneously > # by multiple processes, but it's needed for reliable reading if no other > # locking methods are available. > #mbox_read_dotlock = no > --- > means that if the only other reading accesses to a (mbox style in this > case here) mailbox are via other dovecot processes everything will be fine?Yes, but you should be aware there are other processes than Dovecot which can access the mailbox, moreover in a read-write fashion, such as your MDA (procmail, sendmail, maildrop, whatever). You had better teach them to also use dotlock files to be safe. -- olive
On Tue, 2004-05-18 at 15:10, Christian Balzer wrote:> # Should we create dotlock file even when we want only a read-lock? Setting > # this to yes hurts the performance when the mailbox is accessed simultaneously > # by multiple processes, but it's needed for reliable reading if no other > # locking methods are available. > #mbox_read_dotlock = no > --- > means that if the only other reading accesses to a (mbox style in this > case here) mailbox are via other dovecot processes everything will be fine?This setting only means that we use dotlock also for read-locking, not just write-locking mbox. Normally it uses just fcntl/flock. Hmm. I think I should change the description a bit. So, currently Dovecot doesn't try to lock mbox for the whole POP3 session. That may create problems if two sessions actually try to access the mailbox concurrently. If message gets expunged by another process, Dovecot replies with -ERR to requests to fetch the message. That might confuse some POP3 clients, or cause them to send errors to user. I don't think normally anyone even tries concurrent POP3 access? Anyway, I have thought before that Dovecot/pop3 should lock the mbox for the whole time, just like all others POP3 servers do (and RFC says too).. I'll add in TODO. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: <http://dovecot.org/pipermail/dovecot/attachments/20040522/35b5373b/attachment-0001.bin>
Timo wrote:> >So, currently Dovecot doesn't try to lock mbox for the whole POP3 >session. That may create problems if two sessions actually try to access >the mailbox concurrently. If message gets expunged by another process, >Dovecot replies with -ERR to requests to fetch the message. That might >confuse some POP3 clients, or cause them to send errors to user. >That is (for me at least) acceptable as long as there is no danger of actual mailbox corruption (a message gets deleted while another client is actually downloading it). Is this the case in .99.10.4? Again, just expunging something get some things confused, but not lethally so, as tested with a number of clients here. ^^>I don't think normally anyone even tries concurrent POP3 access?Unfortunately the harsh reality of ISP life tells us otherwise, at least with substandard clients on slow links. Typical current scenario: User with Outlook (Express) on an ISDN or dialup link gets a huge mail. The default timeout for that client is 1 minute, after that it just gives up, but w/o our end actually noticing it. The result are the previously mentioned 30 minutes of POP-lock until qpopper gives up itself or the user tears down the PPP session which gets the message across to qpopper, too. Now during the server side imposed lock the user will be told that another POP session is active while that isn't true from their point of view of course. With the current dovecot they can try again immediately, of course failing again on the large email but the consistent error given might lead them to the right course of action: Get better software, a better link or at least configure your current setup correctly. ;)>Anyway, >I have thought before that Dovecot/pop3 should lock the mbox for the >whole time, just like all others POP3 servers do (and RFC says too).. >I'll add in TODO. >If the RFC requires it, there will be no argument from me, though more granular locks which prevent really bad things from happening are sufficient for me and as detailed above might be more responsive. Also you are saying mbox up there, would a maildir storage accessed via POP3 really be immune to these possibly confusing effects for clients? Regards, Christian Balzer -- Christian Balzer Network/Systems Engineer NOC chibi at gol.com Global OnLine Japan/Fusion Network Services http://www.gol.com/
Timo Sirainen wrote:> ... currently Dovecot doesn't try to lock mbox for the whole POP3 > session. That may create problems if two sessions actually try to access > the mailbox concurrently. If message gets expunged by another process, > Dovecot replies with -ERR to requests to fetch the message. That might > confuse some POP3 clients, or cause them to send errors to user. > >Is there currently any way to enforce mbox r/w locking for the entire pop3 session in Dovecot? We're considering migrating from qpopper and need a pop3 server that enforces locking while a session is active. Thanks, Ken A> I don't think normally anyone even tries concurrent POP3 access? Anyway, > I have thought before that Dovecot/pop3 should lock the mbox for the > whole time, just like all others POP3 servers do (and RFC says too).. > I'll add in TODO. > >