disable IMAP IDLE

[Ian Eiloart]

--On 23 November 2010 10:19:28 -0500 Chris Mattingly <chris at camattin.com> 
wrote:

>
>
> The RFC for the IDLE says:
>
> This document specifies the syntax of an IDLE command, which will
> allow a client to tell the server that it's ready to accept such
> real-time updates.
>
> This doesn't say anything about keeping connections open, it only talks
> about the near-instant new email notification.

IDLE requires the session to remain open, doesn't it? After all, nothing in 
the spec allows the client to say how it can be contacted. The open session 
is used for the notification.

In fact, RFC 2177 says this about keeping sessions open:

    "The server MAY consider a client inactive if it has an IDLE command
   running, and if such a server has an inactivity timeout it MAY log
   the client off implicitly at the end of its timeout period.  Because
   of that, clients using IDLE are advised to terminate the IDLE and
   re-issue it at least every 29 minutes to avoid being logged off.
   This still allows a client to receive immediate mailbox updates even
   though it need only "poll" at half hour intervals."


> -Chris
>
> On 11/23/2010 10:01 AM, Ron Vachiyer wrote:
>>
>>
>> > Date: Tue, 23 Nov 2010 14:44:34 +0000
>> > From: iane at sussex.ac.uk
>> > To: proutfoo at hotmail.com; info-cyrus at lists.andrew.cmu.edu
>> > Subject: Re: disable IMAP IDLE
>> >
>> >
>> >
>> > --On 22 November 2010 18:40:37 -0500 Ron Vachiyer
>> <proutfoo at hotmail.com>
>> > wrote:
>> >
>> > >
>> > > Hello,
>> > >
>> > > I thought it was possible in Cyrus to disable the IDLE functionality,
>> > > either with imapidlepoll: 0 in imapd.conf, or by commenting idled in
>> > > cyrus.conf. However, having both disabled, clients still connect and
>> > > maintain their socket open on tcp 143. Is it not possible or am I
>> going
>> > > about it wrong?
>> >
>> > I thought sessions remained open for efficiency, regardless of IDLE,
>> until
>> > closed by the client or 30 minutes have elapsed.
>> >
>> > IDLE just lets the server notify the client if new email arrives,
>> doesn't
>> > it?
>> >
>> > Even without IDLE, there are benefits in leaving the session open.
>>
>> Hello,
>>
>> I won't argue since clearly I am in the minority ;)  Using
>> courier-imap on our Plesk servers, TCP/143 is closed after every new
>> mail verification.  A dovecot server I checked does the same.  Cyrus
>> seems to allow the session to be maintained, and yes, it does not
>> advertise IDLE.
>>
>> Below is an example courier-imap capability;
>>
>> * OK [CAPABILITY IMAP4rev1 UIDPLUS CHILDREN NAMESPACE
>> THREAD=ORDEREDSUBJECT THREAD=REFERENCES SORT QUOTA ACL ACL2=UNION
>> STARTTLS] Courier-IMAP ready. Copyright 1998-2004 Double Precision,
>> Inc.  See COPYING for distribution information.
>> . CAPABILITY
>> * CAPABILITY IMAP4rev1 UIDPLUS CHILDREN NAMESPACE
>> THREAD=ORDEREDSUBJECT THREAD=REFERENCES SORT QUOTA ACL ACL2=UNION
>> STARTTLS
>>
>>
>> this one is cyrus 2.4.4
>>
>> . capability
>> * CAPABILITY IMAP4rev1 LITERAL+ ID ENABLE STARTTLS AUTH=PLAIN SASL-IR
>> ACL RIGHTS=kxte QUOTA MAILBOX-REFERRALS NAMESPACE UIDPLUS
>> NO_ATOMIC_RENAME UNSELECT CHILDREN MULTIAPPEND BINARY CATENATE
>> CONDSTORE ESEARCH SORT SORT=MODSEQ THREAD=ORDEREDSUBJECT
>> THREAD=REFERENCES ANNOTATEMORE LIST-EXTENDED WITHIN QRESYNC SCAN XLIST
>> URLAUTH URLAUTH=BINARY X-NETSCAPE COMPRESS=DEFLATE
>> . OK Completed
>>
>> I was asked by IT to not permit IDLE since the current server went
>> down after 4-500 blackberries ate up all the (limited) capabilities of
>> that machine.    Perhaps I am looking in the wrong place, the point is
>> the demand I am facing is to have IMAP that essentially behaves as a
>> POP3 client when it comes to inbox scans.
>>
>> I believe there was an issue as well where POP clients using outlook
>> would cause mailbox corruption when they popped a mailbox being
>> maintained by a blackberry connected via IMAP.
>>
>> R.
>>
>>
>> ----
>> Cyrus Home Page: http://www.cyrusimap.org/
>> List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
>



-- 
Ian Eiloart
IT Services, University of Sussex
01273-873148 x3148
For new support requests, see http://www.sussex.ac.uk/its/help/