Bug#879007: cyrus-imapd does not accept new connections

[Thadeu Lima de Souza Cascardo]

Source: cyrus-imapd
Followup-For: Bug #879007

So, after further investigation, I found out that I had too many imapd
children, and master does not wait for new connections after that
(maxchild is a setting in master).

So, after killing all children and waiting for some connections to
linger, I noticed some of them were not timeing out (the usual timeout
of 30 minutes if nothing is received from the client). Only after using
gdb, I saw that it was waiting on the IDLE execution. And I know for a
fact that those clients were long gone from the TCP side (mobile
connection now changed to wifi). Problem is they were idling on Draft
mailboxes I almost never add to.

It turns out imapd should just consider the same timeout as usual in
those cases. Looking upstream, I found commit
d7199761f42da09984bbd2e4a29390481fb8184e ("imapd.c: imapoptions:
implement idle timeout"), detailed message below.

Is it possible to backport this to stable and do a stable update?

Thank you very much.
Cascardo.


commit d7199761f42da09984bbd2e4a29390481fb8184e
Author: Philipp Gesang <philipp.gesang at intra2net.com>
Date:   Wed Sep 21 17:26:40 2016 +0200

    imapd.c: imapoptions: implement idle timeout

    Use the value of the configuration variable "timeout" as an upper
    limit in minutes for idle connections. To allow further
    customization, add a new configuration option "imapidletimeout"
    which, if greater than zero, will be used instead. The value
    defaults to zero (not set).

    RFC 2177 recommends that a client re-issue the IDLE command at
    least every 29 minutes if it wishes to continue, otherwise the
    server is free to treat the client as disconnected.

    The rationale is that sometimes connections aren't properly
    reset. Currently, a connection is not collected if it was in IDLE
    state at that point. If this happens repeatedly, imapd keeps
    accumulating dead connections which can cause DOS. This patch
    solves the problem by forcing imapd to stop idling after
    exceeding the configured timeout.




-- System Information:
Debian Release: buster/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armhf

Kernel: Linux 4.13.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=pt_BR.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)