[RFC PATCH v2] imapd.c: imapoptions: implement idle timeout

[ellie timoney]

> time jumps issued via NTP are a recurring source of trouble.
> On our distribution we have detection logic for that and restart
> quite a few services if it happens. The monotonic clock avoids that
> nicely.

Or does it?  The man page says it's "not  affected by discontinuous
jumps in the system time (e.g., if the system administrator manually
changes the clock)" -- great -- "but is affected by the incremental
adjustments performed by adjtime(3) and NTP".  Which sounds to me like
NTP might still be an issue?   (But: I have no real world experience of
this, I'm just reading man pages here.)

> Would it make sense to enable the timeout by default?
> In the current version of the patch it's disabled (value 0).

I'm interested in hearing thoughts on this, particularly with regard to
what a reasonable default timeout might be.  Though I like the "no
behaviour change unless you change configuration" aspect of defaulting
to 0.

> We plan on rolling it out with a default value of three days
> for our systems. That's enough to keep workstations that are left on
> over the weekend happy, but short enough to clean up "forgotten" clients
> idling on the INBOX/Drafts folder. There are still quite a few
> Outlook 2007 installations with broken IMAP IDLE handling in the wild,
> so the RFC recommended timeout of 29 minutes is unsuitable.

As I understand it, the RFC's recommendation of "29 minutes" applies to
clients wishing to avoid being timed out by breaking/resuming idle
early, from which I take the implication that a reasonable server might
time out connections after 30 mins.  But, Outlook...

Cheers,

ellie

On Thu, Sep 8, 2016, at 11:26 PM, Thomas Jarosch wrote:
> Hi Ellie,
> 
> On Thursday, 8. September 2016 11:07:54 ellie timoney via Cyrus-devel
> wrote:
> > I can kind of see a point about the ability to request a monotonic
> > clock, such that some sysadmin changing the system time doesn't
> > prematurely timeout a bunch of idle connections.  Though that doesn't
> > seem likely to be a real problem in practice (a: don't do that, b: the
> > clients will just reconnect in a bit anyway).
> 
> time jumps issued via NTP are a recurring source of trouble.
> On our distribution we have detection logic for that and restart
> quite a few services if it happens. The monotonic clock avoids that
> nicely.
> 
> > Anyway, the patch applies cleanly, builds fine for me, and passes our
> > current tests.  I'll try and put together a couple of Cassandane tests
> > for the new behaviour and see what shakes out of that.
> 
> Would it make sense to enable the timeout by default?
> In the current version of the patch it's disabled (value 0).
> 
> We plan on rolling it out with a default value of three days
> for our systems. That's enough to keep workstations that are left on
> over the weekend happy, but short enough to clean up "forgotten" clients
> idling on the INBOX/Drafts folder. There are still quite a few
> Outlook 2007 installations with broken IMAP IDLE handling in the wild,
> so the RFC recommended timeout of 29 minutes is unsuitable.
> 
> Cheers,
> Thomas
>