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 kickthem, 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.
- Solve the 30 min firewall timeout issue: replace firewall
- Possibly solve the dodgy cable modem issue: install an imapproxy box