Re: Does anyone allow unlimited or extremely large quotas?
tarball. Just sending a mail in LMTP and opening the mailbox several times (SELECT/CLOSE only) A binary diff indicated that Generation Number is incremented but nothing else. Oh yeah - expunge on close. God, that's awful. 2.4.x will fix that. Switching filehandles to read-only won't help, because the standard says to expunge on close! I expect that cyrus.index and cyrus.cache don't change if the client does nothing in the IMAP session, even after a SELECT. The same test in an empty mailbox has the same result, Generation Number is incremented too. If you actually WANT read-only, the command is called 'EXAMINE' by the way. It's like SELECT, but actually supposed to be read-only. Thanks a lot, but I know IMAP :-) I can't do anything on the client side. For mailboxes that don't change and don't have any \Deleted flag I would like to change on the server side any CLOSE by UNSELECT Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: Does anyone allow unlimited or extremely large quotas?
Thanks a lot for the tip, I didn't know this tool. Sébastien 2010/11/22 Gabor Gombas gomb...@digikabel.hu On Mon, Nov 22, 2010 at 11:03:15AM +0100, Sébastien Michel wrote: Since strace doesn't help to see what mmap reads on SELECT, so I made a test on NFS server. On Linux you should use blktrace. NFS is a non-POSIX filesystem, and it may show quite different behavior compared to a POSIX filesystem on a real block device. Gabor Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: Does anyone allow unlimited or extremely large quotas?
On Tue, Nov 23, 2010 at 10:09:43AM +0100, Sébastien Michel wrote: I expect that cyrus.index and cyrus.cache don't change if the client does nothing in the IMAP session, even after a SELECT. The same test in an empty mailbox has the same result, Generation Number is incremented too. Cyrus 2.3.16 doesn't care - it re-packs the whole mailbox every time mailbox_expunge gets called. If you actually WANT read-only, the command is called 'EXAMINE' by the way. It's like SELECT, but actually supposed to be read-only. Thanks a lot, but I know IMAP :-) I can't do anything on the client side. For mailboxes that don't change and don't have any \Deleted flag I would like to change on the server side any CLOSE by UNSELECT So upgrade to 2.4.x, it's fixed there. It was a massive amount of work, and it's not going to backport cleanly. I've shown mailbox_expunge to our new Cyrus programmer (Greg) and he asked me to stop before we got half way through. It was over a thousand lines of complex code. Bron. Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: Does anyone allow unlimited or extremely large quotas?
Thanks a lot, but I know IMAP :-) I can't do anything on the client side. For mailboxes that don't change and don't have any \Deleted flag I would like to change on the server side any CLOSE by UNSELECT So upgrade to 2.4.x, it's fixed there. It was a massive amount of work, and it's not going to backport cleanly. I've shown mailbox_expunge to our new Cyrus programmer (Greg) and he asked me to stop before we got half way through. It was over a thousand lines of complex code. It seems to be a good advice. I will test such version of Cyrus. Thanks, Sébastien Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Cyrus Upgradation
Hi I need to upgrade my cyrus from 2.3 to the newer version 2.4 without disturbing my entire setup so i was trying to get 2.4 rpm but I couldn't find cyrus rpm for 2.4 version. where I can directly upgrade Cyrus through yum. So can any one help me to get Cyrus-2.4 rpm. Thanks / Regards Sachin Murudkar Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
RE: disable IMAP IDLE
From how I understand the RFC, if no IMAP IDLE capability is advertised, the client should not attempt to use it and should close the TCP socket after every operation. Backberry connections to courier-imap and dovecot will not maintain a TCP session, they seem to when Cyrus is the IMAP server. R. Date: Tue, 23 Nov 2010 06:38:28 +0100 Subject: Re: disable IMAP IDLE From: simon.mat...@invoca.ch To: prout...@hotmail.com CC: info-cyrus@lists.andrew.cmu.edu 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 may be completely wrong but as I understand it the IMAP client may always keep connection on port 143 established, IDLE just changes the way how the client learns about new messages and such. Regards, Simon Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: disable IMAP IDLE
On 11/23/2010 08:52 AM, Ron Vachiyer wrote: From how I understand the RFC, if no IMAP IDLE capability is advertised, the client should not attempt to use it and should close the TCP socket after every operation. Backberry connections to courier-imap and dovecot will not maintain a TCP session, they seem to when Cyrus is the IMAP server. Is your server advertising IDLE ? telnet to port 143 and issue this command: . CAPABILITY R. Date: Tue, 23 Nov 2010 06:38:28 +0100 Subject: Re: disable IMAP IDLE From: simon.mat...@invoca.ch To: prout...@hotmail.com CC: info-cyrus@lists.andrew.cmu.edu 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 may be completely wrong but as I understand it the IMAP client may always keep connection on port 143 established, IDLE just changes the way how the client learns about new messages and such. Regards, Simon Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ attachment: boutilpj.vcf Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
RE: disable IMAP IDLE
Date: Tue, 23 Nov 2010 08:57:52 -0400 From: bouti...@ednet.ns.ca To: info-cyrus@lists.andrew.cmu.edu Subject: Re: disable IMAP IDLE On 11/23/2010 08:52 AM, Ron Vachiyer wrote: From how I understand the RFC, if no IMAP IDLE capability is advertised, the client should not attempt to use it and should close the TCP socket after every operation. Backberry connections to courier-imap and dovecot will not maintain a TCP session, they seem to when Cyrus is the IMAP server. Is your server advertising IDLE ? telnet to port 143 and issue this command: . CAPABILITY Hello, No it isn't, I had already checked and strangely it is notwhich is really surprising me that the sessions remain; * OK [CAPABILITY IMAP4rev1 LITERAL+ ID ENABLE STARTTLS AUTH=PLAIN SASL-IR] node1 Cyrus IMAP v2.4.4-Kolab-2.4.4-1 server ready . 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 might try and recompile using --with-idle=no and see if sessions stay open. R. Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
RE: disable IMAP IDLE
--On Tuesday, November 23, 2010 9:15 -0500 Ron Vachiyer prout...@hotmail.com wrote: No it isn't, I had already checked and strangely it is notwhich is really surprising me that the sessions remain; A client can keep a session open by sending NOOP every 25 minutes. If you won't allow IDLE that's probably exactly what a client does. Joseph Brennan Lead Email Systems Engineer Columbia University Information Technology Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: disable IMAP IDLE
--On 22 November 2010 18:40:37 -0500 Ron Vachiyer prout...@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. -- Ian Eiloart IT Services, University of Sussex 01273-873148 x3148 For new support requests, see http://www.sussex.ac.uk/its/help/ Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
RE: disable IMAP IDLE
Date: Tue, 23 Nov 2010 14:44:34 + From: i...@sussex.ac.uk To: prout...@hotmail.com; info-cyrus@lists.andrew.cmu.edu Subject: Re: disable IMAP IDLE --On 22 November 2010 18:40:37 -0500 Ron Vachiyer prout...@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/
Re: disable IMAP IDLE
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. -Chris On 11/23/2010 10:01 AM, Ron Vachiyer wrote: Date: Tue, 23 Nov 2010 14:44:34 + From: i...@sussex.ac.uk To: prout...@hotmail.com; info-cyrus@lists.andrew.cmu.edu Subject: Re: disable IMAP IDLE --On 22 November 2010 18:40:37 -0500 Ron Vachiyer prout...@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/ Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
RE: disable IMAP IDLE
--On 23 November 2010 10:01:58 -0500 Ron Vachiyer prout...@hotmail.com wrote: 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. Then they're doing something other than IMAP4rev1, which is requires servers to keep a session open for 30 minutes of inactivity. http://www.apps.ietf.org/rfc/rfc2060.html#sec-5.4 Of course, if the client logs out, then the TCP session should be disconnected. -- Ian Eiloart IT Services, University of Sussex 01273-873148 x3148 For new support requests, see http://www.sussex.ac.uk/its/help/ Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
rsync and cyrusimap.2.4.x
Hello, with 2.3.X we were happy by having a standby-system for our mail server, keeping the data up to date by a periodical rsync from the working system. We did an upgrade to 2.4.X on the standby-system. With 2.4.X reconstruct seems to change the modification-time of all mail-files, on next invocation that triggers rsync to transfer all files, which causes too much load and takes too much time. Is the only solution for this the use of replication instead of rsync? Thanks Martin Pracht Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: disable IMAP IDLE
--On 23 November 2010 10:19:28 -0500 Chris Mattingly ch...@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 + From: i...@sussex.ac.uk To: prout...@hotmail.com; info-cyrus@lists.andrew.cmu.edu Subject: Re: disable IMAP IDLE --On 22 November 2010 18:40:37 -0500 Ron Vachiyer prout...@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/ Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: cyr_expire does not delete files on disk with expunge_mode:delayed?
On Tue, 23 Nov 2010, Bron Gondwana wrote: On Mon, Nov 22, 2010 at 03:03:05PM -0600, Kenneth Marshall wrote: We hit the same issue. You will need to run cyr_expire twice to have items be removed correctly. Once as you are currently doing and then a second time ignoring the mailbox annotations (the -a option). This will actually run the delete. That would be my fault :( The bug that causes this. Of course we always run with -a at FastMail, hence I didn't notice it. This bug is also fixed in Cyrus 2.4.x. Bron, this one, while not nasty, is very annoying. Is it easy to backport the fix to 2.3? Since the 2.3 tree is not dead yet (2.4 is good, but not rock stable yet), it might be worth it... -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: disable IMAP IDLE
On 23/11/10 10:01 -0500, Ron Vachiyer wrote: 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. I have doubts that either of those IMAP servers would close the connection out from underneath a client, without the client issuing a logout, closing the TCP connection, or with the server hitting a 30 minute timeout. More than likely, something else is happening that is unrelated to IDLE, like a bug in the client (not sending a logout) or in the server, or with a firewall complicating things. How are you determining that the connections are staying open. Do you see them in netstat? Can you set up telemetry logging, or do a pcap trace to see what's going on? -- Dan White Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: disable IMAP IDLE
IDLE does require the session to stay open. But the server doesn't have to support IDLE for the client to keep the connection open. -Chris On 11/23/2010 11:20 AM, Ian Eiloart wrote: --On 23 November 2010 10:19:28 -0500 Chris Mattingly ch...@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 + From: i...@sussex.ac.uk To: prout...@hotmail.com; info-cyrus@lists.andrew.cmu.edu Subject: Re: disable IMAP IDLE --On 22 November 2010 18:40:37 -0500 Ron Vachiyer prout...@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/ Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: cyr_expire does not delete files on disk with expunge_mode:delayed?
On Tue, Nov 23, 2010 at 03:10:48PM -0200, Henrique de Moraes Holschuh wrote: On Tue, 23 Nov 2010, Bron Gondwana wrote: On Mon, Nov 22, 2010 at 03:03:05PM -0600, Kenneth Marshall wrote: We hit the same issue. You will need to run cyr_expire twice to have items be removed correctly. Once as you are currently doing and then a second time ignoring the mailbox annotations (the -a option). This will actually run the delete. That would be my fault :( The bug that causes this. Of course we always run with -a at FastMail, hence I didn't notice it. This bug is also fixed in Cyrus 2.4.x. Bron, this one, while not nasty, is very annoying. Is it easy to backport the fix to 2.3? Since the 2.3 tree is not dead yet (2.4 is good, but not rock stable yet), it might be worth it... Yes, probably. I'll have a look at it today. Have just filed a bugzilla about it. Bron. Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: disable IMAP IDLE
On Tue, Nov 23, 2010 at 10:01:58AM -0500, Ron Vachiyer wrote: 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. Not in 2.4.x there shouldn't be. The locking system is much more simple and robust. Bron. Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
RE: disable IMAP IDLE
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. I'd really be surprised if that was a problem these days. We have machines that have 1 connections quite fine. Yes they're fairly loaded servers with fast IO and lots of RAM, but even a pretty basic server should handle 500 connections no problem. Have you actually tested that long lived IDLE connections are a problem? Rob Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
RE: disable IMAP IDLE
On Wed, 24 Nov 2010, Robert Mueller wrote: 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. I'd really be surprised if that was a problem these days. We have machines that have 1 connections quite fine. Yes they're fairly loaded servers with fast IO and lots of RAM, but even a pretty basic server should handle 500 connections no problem. Have you actually tested that long lived IDLE connections are a problem? if they are idle they eat up very few resources, if they are checking things frequently, forcing them to reconnect each time will just eat up more resources. David Lang Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
