[Dovecot] Dovecot 2 and TCP-Keepalive

2012-10-20 Thread Sven Hartge
Hi!

I am about to migrate a perdition-based IMAP/POP3 proxy to Dovecot.

Unfortunately some users are behind a firewall/NAT setup which throws
away seemingly idle TCP connections sooner than the established default
of 24 hours (more likely after 30 minutes ...) resulting in all kinds of
weird client behavior.

And unfortunately² this firewall/NAT setup is outside of my control and
I have no means of correcting this (in my opinion) flawed configuration.

Now, with perdition I was able to use the --tcp_keepalive option which
totally solved the mentioned weird client behavior.

My question is: does Dovecot2 use TCP-Keepalive on its sockets per
default or do I need to enable it some way I have not yet discovered?

The manual and wiki only talk about keepalive in connection with the
IMAP protocol and IDLE and my C-fu is too weak to understand the source
code.

Grüße,
Sven.


-- 
Sigmentation fault. Core dumped.



Re: [Dovecot] Dovecot 2 and TCP-Keepalive

2012-10-20 Thread Timo Sirainen
On 20.10.2012, at 19.39, Sven Hartge wrote:

 I am about to migrate a perdition-based IMAP/POP3 proxy to Dovecot.
 
 Unfortunately some users are behind a firewall/NAT setup which throws
 away seemingly idle TCP connections sooner than the established default
 of 24 hours (more likely after 30 minutes ...) resulting in all kinds of
 weird client behavior.
 
 And unfortunately² this firewall/NAT setup is outside of my control and
 I have no means of correcting this (in my opinion) flawed configuration.
 
 Now, with perdition I was able to use the --tcp_keepalive option which
 totally solved the mentioned weird client behavior.
 
 My question is: does Dovecot2 use TCP-Keepalive on its sockets per
 default or do I need to enable it some way I have not yet discovered?

It's the default yes. Of course Linux's default keepalive interval is something 
like 90 minutes, so have you changed that already?..

 The manual and wiki only talk about keepalive in connection with the
 IMAP protocol and IDLE and my C-fu is too weak to understand the source
 code.

imap_idle_notify_interval (default 2 min) causes Dovecot to send data to 
IDLEing connections, which pretty much makes the TCP keepalive irrelevant. For 
non-IDLE connections Dovecot has a disconnect timeout of 30 minutes.

Re: [Dovecot] Dovecot 2 and TCP-Keepalive

2012-10-20 Thread Sven Hartge
Timo Sirainen t...@iki.fi wrote:
 On 20.10.2012, at 19.39, Sven Hartge wrote:

 My question is: does Dovecot2 use TCP-Keepalive on its sockets per
 default or do I need to enable it some way I have not yet discovered?

 It's the default yes. Of course Linux's default keepalive interval is
 something like 90 minutes, so have you changed that already?..

Yes, I did. For those systems it is set to 15 minutes right now.

 The manual and wiki only talk about keepalive in connection with
 the IMAP protocol and IDLE and my C-fu is too weak to understand the
 source code.

 imap_idle_notify_interval (default 2 min) causes Dovecot to send data
 to IDLEing connections, which pretty much makes the TCP keepalive
 irrelevant. For non-IDLE connections Dovecot has a disconnect timeout
 of 30 minutes.

This is fine. As long as the client notices the termination of the
connection, everything should be OK.

Before I switched keepalive on for Perdition, the firewall/NAT would
internally throw away a connection but neither the client or the server
would notice this.

Then if the client tried to do something with this connection, like
select or save a message, the firewall/NAT would send a RST and the
client would then bug the user with a meaningless message like folder
does not exist which caused a lot of confusion for the end-user and
created quite the bit of trouble tickets.

This problem mostly happend with an IMAP connection to the Sent
Messages folder which normally does not see much changes until the
users writes and sends a mail. Then after the mail was sent via SMTP the
client tries to save the message, gets sent an RST from the firewall/NAT
and presents the user with a wrong and confusing error message. The user
then thinks his mail was not sent and sends it again. This time the
client opens a new connection to select the Sent Messages folder and
everything works. But the recipient gets the mail twice.

Again resulting in confusion and trouble tickets to be dealt with.

By switching to TCP keepalive (and reducing the keepalive time to 15
minutes) all those problems were solved and my users (and support staff)
were happy again ;)

Grüße,
Sven.

-- 
Sigmentation fault. Core dumped.