Controlling inactivity timeout for IMAP

[Joseph Tam]

Andr? Peters writes:

> > I have a problem with a user who uses a wireless carrier that keeps
> > changing his IP as he travels throughout the city.  From the perspective
> > of our dovecot IMAP server, the user keeps logging in from another IP,
> > and after a short while, hits up against the mail_max_userip_connections
> > limit.  It takes 30 minutes before those orphaned connections times out.
> >
> > Is there any way to decrease the IMAP idle timeout other than to
> > recompile dovecot with a new value?
> >
> >      imap-common.h:#define CLIENT_IDLE_TIMEOUT_MSECS (60*30*1000)
> >
> > For example, will this work?
> >
> >      service imap {
> >          idle_kill = 600
> >      }
> 
> I was following this in hope someone would answer.
> 
> As a workaround I recommend to set up a POP3 connection with a low 
> polling interval (besides using a TCP Proxy...).

I'll give that a try -- I'll probably still get the odd orphaned process
if the client changed address in the middle of a POP session.

To close this out, I'll relate my experiments to asnwer the question
I posed above in case it's of use to someone.

Changing pre-authentication timeouts.  The default is 3 minutes
hardcoded at

  	diff -r -U0 a/src/lib-master/master-interface.h b/src/lib-master/master-interface.h
  	--- a/src/lib-master/master-interface.h Mon Jun  2 04:50:10 2014
  	+++ b/src/lib-master/master-interface.h Sat Feb 14 18:41:39 2015
  	@@ -99,1 +99,1 @@
  	-#define MASTER_LOGIN_TIMEOUT_SECS (3*60)
  	+#define MASTER_LOGIN_TIMEOUT_SECS (31)

  	Changing it to 31s still seems overly generous, but you can not
  	set it lower unless you also change the next define

  	/* auth server should abort auth requests before that happens */
  	#define MASTER_AUTH_SERVER_TIMEOUT_SECS (MASTER_LOGIN_TIMEOUT_SECS - 30)

  	I really don't understand what this is about, but if this
  	becomes zero, authentication breaks.  Maybe (MASTER_LOGIN_TIMEOUT_SECS>>1)
  	would be a safer definition.

  	$ date; netcat 127.0.0.1 143; date
  	Mon Feb 16 15:23:44 EST 2015
  	* OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE IDLE STARTTLS AUTH=PLAIN] Ready.
  	* BYE Disconnected for inactivity.
  	Mon Feb 16 15:24:15 EST 2015

Changing post-authentication IMAP idle timeout

  	The default (RFC minimum) is 30 minutes, which can be changed here

  	diff -r -U0 a/src/imap/imap-common.h b/src/imap/imap-common.h
  	--- a/src/imap/imap-common.h    Mon Jun  2 04:50:10 2014
  	+++ b/src/imap/imap-common.h    Sat Feb 14 18:44:24 2015
  	@@ -5,1 +5,1 @@
  	-#define CLIENT_IDLE_TIMEOUT_MSECS (60*30*1000)
  	+#define CLIENT_IDLE_TIMEOUT_MSECS (60*15*1000)

  	I also tried changing it in dovecot.conf

  	service imap {
  		idle_kill = 630
  	}

  	but after recompiling/reconfiguring with both options,
  	idle_kill has no influence.

  	$ date ; echo . login user password | netcat 127.0.0.1 143 ; date
  	Mon Feb 16 15:47:10 EST 2015
  	* OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE IDLE STARTTLS AUTH=PLAIN] Ready.
  	. OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE IDLE SORT SORT=DISPLAY THREAD=REFERENCES THREAD=REFS THREAD=ORDEREDSUBJECT MULTIAPPEND URL-PARTIAL CATENATE UNSELECT CHILDREN NAMESPACE UIDPLUS LIST-EXTENDED I18NLEVEL=1 CONDSTORE QRESYNC ESEARCH ESORT SEARCHRES WITHIN CONTEXT=SEARCH LIST-STATUS SPECIAL-USE BINARY MOVE] Logged in
  	* BYE Disconnected for inactivity.
  	Mon Feb 16 16:02:11 EST 2015

General notes:

  	Dovecot is chock full of these ad-hoc/default/RFC timeout
  	definitions.  The interaction of these timeouts between dovecot's
  	internal components as well as remote clients is complex, and
  	could cause problems if you change them.

  	For example, our webmail system opens persistent IMAP connections,
  	and if you set dovecot's idle timeout less than the webmail's
  	idle timeout, the user will get an annoying re-login requests.

  	It would be nice if this problem of mobile WiFi mail readers
  	acquiring (and abandoning) new IPs could be handled in a more
  	gracious way (reaping on a expedited schedule or LRU basis),
  	but unless you really have to and know what you are doing,
  	I would suggest not modifying timeouts.

Joseph Tam <jtam.home at gmail.com>