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
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
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
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
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
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
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,
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
--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
--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
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
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
--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
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
--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
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
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
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
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
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
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
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
22 matches
Mail list logo
