[Dovecot] Mailbox locking problem with iphone and POP3
I have a problem I can't seem to fix. I have dovecot configured to do
POP3 with plain text authentication using a MySQL database. I am using Dovecot 1.0.7 with fcntl locking.
My problem has been when an iPhone/iPod checks email. The iPhone/iPod
doesn't disconnect with a TCP FIN packet and it leaves the mailbox in a locked state and prevents the user's desktop from checking email. I have tried changing the file locking method and other config file options without any luck.
Oddly, I am using the last version of cucipop on another server with
fcntl and lockf file locking and it doesn't have this problem.
If someone could clue me in I'd be very grateful.
Bill
On Mon, 2009-08-03 at 10:47 -0500, Bill Dunn - VCI Internet Services wrote:
I have a problem I can't seem to fix. I have dovecot configured to do POP3 with plain text authentication using a MySQL database. I am using Dovecot 1.0.7 with fcntl locking.
So you're using mbox format?
My problem has been when an iPhone/iPod checks email. The iPhone/iPod
doesn't disconnect with a TCP FIN packet and it leaves the mailbox in a locked state and prevents the user's desktop from checking email. I have tried changing the file locking method and other config file options without any luck.
Do you have pop3_lock_session=no?
On Fri, 7 Aug 2009, Timo Sirainen wrote:
On Mon, 2009-08-03 at 10:47 -0500, Bill Dunn - VCI Internet Services wrote:
I have a problem I can't seem to fix. I have dovecot configured to do POP3 with plain text authentication using a MySQL database. I am using Dovecot 1.0.7 with fcntl locking.
So you're using mbox format?
My problem has been when an iPhone/iPod checks
email. The iPhone/iPod doesn't disconnect with a TCP FIN packet and it leaves the mailbox in a locked state and prevents the user's desktop from checking email. I have tried changing the file locking method and other config file options without any luck.
Do you have pop3_lock_session=no?
This is an old thread, but I'm having the same problem.
pop3_lock_session=no
The iphone checks mail, and disconnects uncleanly. Then there is a delivery attempt. I have procmail logging on, and procmail sits there trying to lock the spool file until the timeout is reached and it overrides the lock.
This causes the error "timeout waiting for input from local during Draining Input" in sendmail, which is a generic error that means the delivery process or subprocess generated warning output on stderr.
(Incidentally does anyone know how to get access to procmail's stderr output?)
I've tried a number of different lock combinations. Nothing seems to help. Mail eventually gets delivered, though, so it's not a huge deal at the moment. I don't know how it behaves when the iphone tries to connect again while the box is still locked.
Mark
On Wed, 30 Sep 2009, Mark Hedges wrote:
The iphone checks mail, and disconnects uncleanly. Then there is a delivery attempt. I have procmail logging on, and procmail sits there trying to lock the spool file until the timeout is reached and it overrides the lock.
This causes the error "timeout waiting for input from local during Draining Input" in sendmail, which is a generic error that means the delivery process or subprocess generated warning output on stderr.
(Incidentally does anyone know how to get access to procmail's stderr output?)
I've tried a number of different lock combinations. Nothing seems to help. Mail eventually gets delivered, though, so it's not a huge deal at the moment. I don't know how it behaves when the iphone tries to connect again while the box is still locked.
Hi Bill - did you find a solution for this problem?
Any idea how we can test this?
Or maybe it's not actually a problem, since eventually the locks time out and the mail gets delivered?
Mark
On Wed, 2009-09-30 at 18:08 -0700, Mark Hedges wrote:
This is an old thread, but I'm having the same problem.
pop3_lock_session=no
The iphone checks mail, and disconnects uncleanly. Then there is a delivery attempt. I have procmail logging on, and procmail sits there trying to lock the spool file until the timeout is reached and it overrides the lock.
Are you using mbox or maildir? With mbox I guess this is more or less expected. The solutions I can think of:
a) Switch to maildir.
b) Shrink pop3 idle timeout from 10 minutes to one minute or so. CLIENT_IDLE_TIMEOUT_MSECS in src/pop3/client.c
c) Implement some kind of unlocking feature so Dovecot unlocks mbox file after client has been idling for a few seconds. Seems to me like that would be too much trouble to be worth it.
On Fri, 2 Oct 2009, Timo Sirainen wrote:
Are you using mbox or maildir? With mbox I guess this is more or less expected. The solutions I can think of:
mbox
a) Switch to maildir.
Nope our webmail depends on mbox.
b) Shrink pop3 idle timeout from 10 minutes to one minute or so. CLIENT_IDLE_TIMEOUT_MSECS in src/pop3/client.c
Ergh... maybe i will try this...
c) Implement some kind of unlocking feature so Dovecot unlocks mbox file after client has been idling for a few seconds. Seems to me like that would be too much trouble to be worth it.
Maybe Apple can fix the problem with the iphone client? Hrmm, I have no idea how to report it.
Mark
On Oct 2, 2009, at 9:30 PM, Mark Hedges wrote:
Maybe Apple can fix the problem with the iphone client? Hrmm, I have no idea how to report it.
Do you know what exactly the "disconnects uncleanly" means? Can you
get some tcpdump logs? Either one of these should be fine:
a) Send POP3 "QUIT" message packet, drop connection.
b) Send TCP disconnect packet (whatever it's called), drop connection.
In both cases Dovecot knows that the connection is going away and can
unlock the mailbox. But if iPhone simply drops the connection without
sending anything, that's a bug..
participants (3)
-
Bill Dunn - VCI Internet Services
-
Mark Hedges
-
Timo Sirainen