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 >
