Hello,

I am also in a similar position.

I have a server sitting behind hardware firewall which is configured to timeout all connections in 30 minutes.

So, I would like to set dovecot to 30 minutes.

Could some one please let me know whether it is possible or not, at least.

Thanks in advance.

-- Kind Regards, Sherin

On Thu, Aug 19, 2010 at 4:34 PM, Tamas Kadar <tamas.kadar@espell.com> wrote:

(a) the server is on the internet and the clients are behind the dodgy cable modem.

Yeah, except there are no alternatives to our ISPs at the moment, so I'd rather have a kind-of-solution with shorter timeouts...

KT

-----Original Message----- From: dovecot-bounces+tamas.kadar=espell.com@dovecot.org [mailto:dovecot-bounces+tamas.kadar=espell.com@dovecot.org] On Behalf Of William Blunn Sent: Thursday, August 19, 2010 1:02 PM To: dovecot@dovecot.org Subject: Re: [Dovecot] IMAP connection timeout value?

On 19/08/2010 11:04, Tamas Kadar wrote:

...

So we're having some ISP issues lately, meaning we have to reboot our cable modem like 2-3 times a day. An unfortunate side-effect I've found is, once the users max out their connection limit (which I've set to 10, and many people do), if we reboot the cable modem, they can't log in cause their connections get 'stuck' until I doveadm kick them, or wait for the connections to timeout which takes ??? minutes. Can I adjust that value to something like 30 seconds?

Is it:

(a) your server is on the Internet, and your clients are behind the dodgy cable modem, or

(b) your mail server behind the dodgy cable modem and the clients are out on the Internet

?

Either way I would suggest an improvement to your architecture would be to put the mail server on the same side of the dodgy cable modem as the majority of users.

If you have a mix of office users and out-of-office users, I would say put the mail server on the Internet side. At least then the people struggling out in a hotel in the middle of nowhere won't have to fight your dodgy cable modem as well as their dodgy foreign internet connection.

Bill

Stan Hoeppner put forth on 9/24/2010 12:45 AM:

...

I have a server sitting behind hardware firewall which is configured to timeout all connections in 30 minutes.

...

...

...

So we're having some ISP issues lately, meaning we have to reboot our cable modem like 2-3 times a day. An unfortunate side-effect I've found is, once the users max out their connection limit (which I've set to 10, and many people do), if we reboot the cable modem, they can't log in cause their connections get 'stuck' until I doveadm kick them, or wait for the connections to timeout which takes ??? minutes. Can I adjust that value to something like 30 seconds?

I think you're both out of luck WRT Dovecot:

$ grep timeout /etc/dovecot/dovecot.conf #mbox_lock_timeout = 300 #mbox_dotlock_change_timeout = 120

In the case of the firewall timeout issue, if it's not configurable and the 30 min limit is hard coded, throw that POS out the windows and get something decent. You can build your own as powerful as most "hardware" units with a $500 server, Linux, and if you need a GUI there's IPcop, Shorewall, etc. You know it's a major problem and yet you live with it? Can you point me to the RFC that states all TCP sessions should be closed after 30 minutes? [...]

In the case of the dodgy cable modem, would you expect Ford/GM/Chrysler/Toyota/Honda/etc to re-engineer the engine control computers on their cars to allow running on a 90/10 mix of gasoline/water because *all* of the service stations in your town or the surrounding area where you can get fuel have perennial problems with water in their underground tanks?

In both cases you're asking your application server to deal with problems totally outside its realm of responsibility. In both cases, adding imapproxy in front of the Dovecot servers *might* help to an extent since it proxies all connections. If the MUAs are smart enough to realize their IP sessions have been terminated and try to reconnect after the firewall or cable modem goes down/up, imapproxy may help, as it will be sitting between the "problem" and the Dovecot server. Thus, when the MUAs reconnect, imapproxy should reconnect them to the Dovecot server over an existing IMAP/S connection, avoiding the concurrent connection issue. Although, implementing imapproxy will require the concurrency per

should not require increasing 'mail_max_userip_connections = 10'

Given your circumstances it may be worth a shot, especially in the dodgy cable modem case. In the case of the crappy "hardware" firewall, the cost of a FOSS firewall solution is the same as an imapproxy box, as the software is free and the hardware cost is the same.

1. Solve the 30 min firewall timeout issue: replace firewall
2. Possibly solve the dodgy cable modem issue: install an imapproxy box

Hi,

I could see following in RFC 2683 & RFC 2060.

"To alleviate this, a server may implement an inactivity timeout, unilaterally closing a session (after first sending an untagged BYE, as noted above). Some server operators have reported dramatic improvements in server performance after doing this. As specified in [RFC-2060], if such a timeout is done it must not be until at least 30 minutes of inactivity. The reason for this specification is to prevent clients from sending commands (such as NOOP) to the server at frequent intervals simply to avert a too-early timeout. If the client knows that the server may not time out the session for at least 30 minutes, then the client need not poll at intervals more frequent than, say, 25 minutes."

So, shouldn't an imap server like dovevot be configured with 30 minutes timeout.

-- Kind Regards, Sherin

On Fri, Sep 24, 2010 at 11:20 PM, Timo Sirainen <tss@iki.fi> wrote:

On Fri, 2010-09-24 at 10:24 +0530, Sherin George wrote:

...

Hello,

I am also in  a similar position.

I have a server sitting behind hardware firewall which is configured to timeout all connections in 30 minutes.

So, I would like to set dovecot to 30 minutes.

Dovecot never disconnects IDLEing connections, because several clients expect to be able to do that. But I think you can configure kernel to send keepalive notifications more often (default is every 2,5h IIRC) and then it would notice died connections sooner.