Re: Sieve scripts in global namespace and replication
On Thu, 19 Mar 2009, Janne Peltonen wrote: > It appears that my sieve scripts that I have in the global namespace and > that are annotated to certain Cyrus bulletin boards don't get > replicated. Apparently, only user sieve scripts ever get replicated > (when something generates a USER replication event). How do I > (rollingly) replicate the sieve scripts in the global namespace? > > Thanks for any advice. I'd like to ask again this question. Is it possible to replicate the global sieve scripts? How? (It would make sense to start taking backups from the replicas instead of primary servers, but there seems to be a problem with these global sieve scripts.) Thanks, -Jukka Huhta Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
STARTTLS TLS handshake fails after ServerKeyExchange
We have a problem: when connecting to backend servers (with
cyradm/openssl s_client/whatever) the server just hangs in the TLS
handshake after ServerKeyExchange. The reason for this is unknown to
us.
By reading RFC 5246, it seems to me that the client waits for
CertificateRequest or ServerHelloDone which is never received.
The client is stuck in the read system call and imapd is select()ing
something. Nothing happens.
It is strange that this happens in a test environment almost every
time and in a production environment in about 1/3 of the connection
attempts BUT never when connecting to a service running on a local
node, only when connecting to a remote node. A network related issue?
Cyradm fails also when I connect to a frontend and issue a command
that requires cyradm to connect to a remote backend. Otherwise
frontends work fine (without tls_ca_file defined).
After reading tls.c and imapd.c code we came to a conclusion: When
STARTTLS is used, the server wants to ask for a client certificate
regardless of whether the client certificates are in use or not.
Since we are not using them we worked this around by adding a new
config option tls_ask_cert: 0 and using it like the attached patch
shows.
Certainly I don't want to apply this patch in the production
environment before I fully understand what's really going on and is it
at all the right way to fix this problem.
Any hints, ideas, anything?
Running Cyrus 2.3.15 (rpm 2.3.15-4 by Simon Matter) on a CentOS 5.4
cluster (openssl 0.9.8e-12.el5).
-Jukka Huhtadiff -uNr cyrus-imapd-2.3.15.orig/imap/imapd.c cyrus-imapd-2.3.15/imap/imapd.c
--- cyrus-imapd-2.3.15.orig/imap/imapd.c 2009-09-09 16:28:18.0 +0300
+++ cyrus-imapd-2.3.15/imap/imapd.c 2009-11-11 11:42:49.0 +0200
@@ -6856,7 +6856,7 @@
result=tls_init_serverengine("imap",
5,/* depth to verify */
- !imaps, /* can client auth? */
+ config_getswitch(IMAPOPT_TLS_ASK_CERT), /* can client auth? */
!imaps); /* TLS only? */
if (result == -1) {
diff -uNr cyrus-imapd-2.3.15.orig/lib/imapoptions cyrus-imapd-2.3.15/lib/imapoptions
--- cyrus-imapd-2.3.15.orig/lib/imapoptions 2009-09-09 16:28:18.0 +0300
+++ cyrus-imapd-2.3.15/lib/imapoptions 2009-11-11 11:41:07.0 +0200
@@ -1189,6 +1189,9 @@
/* The length of the IMAP server's inactivity autologout timer,
in minutes. The minimum value is 30, the default. */
+{ "tls_ask_cert", 1, SWITCH }
+/* Ask for a client certificate for ALL services (imap, pop3, lmtp, sieve). */
+
{ "tls_ca_file", NULL, STRING }
/* File containing one or more Certificate Authority (CA) certificates. */
Cyrus Home Page: http://cyrusimap.web.cmu.edu/
Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki
List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Cyrus SSL/TLS and StartCom SSL certificates?
On Sat, 21 Nov 2009, Rich Wales wrote: > Recently, I installed new "StartSSL Free" SSL certificates from StartCom > on these servers. After doing so, I could no longer connect securely to > Cyrus in any mode (imaps, imap + starttls, pop3s, pop3 + starttls) -- the > client sat for a long time before timing out, and the syslog messages > on the server spoke vaguely about "STARTTLS negotiation failed", "Fatal > error: tls_start_servertls() failed", etc. I don't know but the symptoms sound familiar (see my previous mail with the subject line "STARTTLS TLS handshake fails after ServerKeyExchange"). We tried to debug the problem by adding some logging to both Cyrus' and OpenSSL's code. The problem may somehow be related to the CA file reading. (My understanding of OpenSSL is too limited but after all it all came down to a return value of -1 from BIO_write library call or something...) Anyway, removing extra CA's from ca-bundle.crt seems to fix it for us too. -Jukka Huhta Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Ghost folders & imapd segfaults
We've had two tricky special cases of folders created by users. The folder names contain an exclamation mark, which, I presume, isn't handled as it should be. The symptom is that the ghost folders get somehow created on a different host than the "real" mailbox. That results in an annoying error from a quota listing script: "This mailbox hierarchy does not exist on a single backend server". The first one was like user.username1.fdasf! which equals (according to cyradm) to fd...@user.username1 with permissions "anyone lrs". I could just add deletion permission to an admin account and dm it. But the other one is trickier. From mailbox list dump: user.username2 1 i16!nkpd username2 lrswipkxtecda anyone p user.username2.Drafts 1 i16!nkpd username2 lrswipkxtecda anyone p user.username2.Folder 1 i16!nkpd username2 lrswipkxtecda anyone p user.username2.Folder! 1 p01!default anyone lrs "Folder" is a regular, working folder. "i16" is the backend server of username2, "nkpd" is her partition, but p01 is a front end host, a proxy! How could this happen? Through some failed folder rename? How come there's "default" as partition? I cannot reproduce this on purpose, but I cannot delete the "Folder! " folder (yes, there seems to be a space) either: imapd process segfaults when trying. See: cyradm> lm user.username2.Folder user.username2.Folder (\HasNoChildren) cyradm> lm "user.username2.Folder! " @user.username2.Folder (\HasNoChildren) cyradm> lm " @user.username2.Folder" @user.username2.Folder (\HasNoChildren) cyradm> sam " @user.username2.Folder" admin all setaclmailbox: admin: lrswipkxtea: cyradm> lm " @user.username2.Folder" cyradm> lm " @user.username2.Folder" [returned to shell, cyradm dies] Maillog has this: Jan 20 15:58:57 pcn7 admin/master[11756]: process 9773 exited, signaled to death by 11 And syslog: Jan 20 15:58:57 pcn7 kernel: imapd[9773]: segfault at rip 0039746796f0 rsp 7fff0ba77da8 error 4 According to gdb, imapd segfaults in strlen(). Of course I don't have debug symbols compiled in... Any hints? (I must admit that cyradm is connecting to another frontend than p01 because I currently can't login to that one as admin without a service break (don't ask).) Running Cyrus 2.3.15 (Simon's -4 RPM release) on a CentOS cluster, mupdate_config=standard. -- Jukka Huhta Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Ghost folders & imapd segfaults
On Wed, 20 Jan 2010, Andrew Morgan wrote:
> I've seen this segfault happen to me in a similar situation where
> the mailbox was listed as created on the frontend.
Okay, this segfault seems to be caused by a missing authentication
mechanism the imapd is assuming to find -- it thinks it's connecting
to a backend. But we don't support digest-md5 on frontends.
The imapd dies after passing xstrdup() a NULL pointer. And the fix
(to the segfault, not to my issue) seems to be dead simple. Attached.
> I think the question here is - does Cyrus allow a non-admin to create a new
> folder on whatever backend they want? Only admins should be allowed to
> specify a partition.
Yes, and the question seems to remain unanswered. Unfortunately I
still don't know how the folder got created.
> > (I must admit that cyradm is connecting to another frontend than p01
> > because I currently can't login to that one as admin without a
> > service break (don't ask).)
>
> I'm pretty sure you can only fix this by issuing "dm " on p01.
Me too -- I'm just waiting to the next service break to try it.
--
Jukka Huhta--- cyrus-imapd-2.3.15/imap/backend.c.orig 2010-01-22 14:49:00.0 +0200
+++ cyrus-imapd-2.3.15/imap/backend.c 2010-01-22 14:49:02.0 +0200
@@ -444,6 +444,13 @@
&ret->capability, AUTO_NO);
}
+if (mechlist == NULL) {
+ syslog(LOG_ERR, "backend_connect(): couldn't get mechanism list");
+ if (!ret_backend) free(ret);
+ close(sock);
+ return NULL;
+}
+
/* now need to authenticate to backend server,
unless we're doing LMTP/CSYNC on a UNIX socket (deliver/sync_client) */
if ((server[0] != '/') ||
Cyrus Home Page: http://cyrusimap.web.cmu.edu/
Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki
List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Nested "INBOX" folders - hard to delete
We have several users with folders like this: user.username.INBOX.INBOX.INBOXINBOX.INBOX.INBOX.INBOX.Deleted Messages (total of 76 INBOXes or something). No doubt the folders are generated by a bug in Apple Mail, but how to get rid of them? Users can't do that by themselves, and no MUA I've tried is able to handle the folders either. I wonder what Cyrus thinks of them, probably doesn't like too long names or something. Cyradm is just giving an error from Cyrus: cyradm> dm user.username.INBOX.* Deleting mailbox user.username.INBOX.INBOX.INBOX.INBOX.INBOX.INBOX.INBOX.INBOX.INBOX.INBOX.INBOX.INBOX.INBOX.INBOX.INBOX.INBOX.INBOX.INBOX.INBOX.INBOX.INBOX.INBOX.INBOX.INBOX.INBOX.INBOX.INBOX.INBOX.INBOX.INBOX.INBOX.INBOX.INBOX.INBOX.INBOX.INBOX.INBOX.INBOX.INBOX.INBOX.INBOX.INBOX.INBOX.INBOX.INBOX.INBOX.INBOX.INBOX.INBOX.INBOX.INBOX.INBOX.INBOX.INBOX.INBOX.INBOX.INBOX.INBOX.INBOX.INBOX.INBOX.INBOX.INBOX.INBOX.INBOX.INBOX.INBOX.INBOX.INBOX.INBOX.INBOX.INBOX.INBOX.INBOX.Deleted Messages...Invalid mailbox name I'd really like to fix the problem without shutting any Cyrus instances down and manually dumping, editing and undumping the mailbox list. Any suggestions? -Jukka Huhta Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Nested "INBOX" folders - hard to delete
On Mon, 29 Mar 2010, Brian Awood wrote: > What version of cyrus are you running? If it's a version 2.3 with > delayed delete enabled, you are likely running into a bug in cyrus. The newest, 2.3.16. This certainly feels like a bug. Not going to debug it this time, though. > If you don't want to shut cyrus down, you can probably use cyr_dbtool to > delete the mailbox entry, then manually cleanup the filesystem. Thanks, I was going to try that but then I first tried to renm the mailboxes to shorter names before dm'ing them, and that did the trick. I thought I had tried it already. So the issue seems to be worked around. -Jukka Huhta Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Nested "INBOX" folders - hard to delete
On Tue, 30 Mar 2010, Bron Gondwana wrote: > That was what I was just about to suggest! I stuck this in our tree: > > http://github.com/brong/cyrus-imapd/commit/669bae9d11bb7bfa12f0fabdedbc18ddaa51f62f > > So anything with multiple INBOX in a row gets blocked. Great! Can we expect to find that in the main Cyrus tree some day? (Simon's rpm would do fine for us too -- I just don't like the idea of maintaining many local modifications to the package.) But still, it's kinda strange that Cyrus lets users create and rename folders they cannot delete. -Jukka Huhta Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Off by one bug in imap_proxy.c:find_free_server()
After wondering why the IMAP CREATE command didn't get proxied to the right backend server with most free space in spool even though serverlist was specified, we isolated a bug from imap_proxy.c's find_free_server() code with my colleague: The first digit of the freespace annotation value gets eaten up when parsing the response. As a result, the comparison of these values gives results in something completely different than what was expected. I filed a bug, #3225. Can someone confirm and fix this, please? BTW, two side notes unrelated to this: 1. If you've ever tried to create new mailboxes by connecting to a frontend but ended up having them created on the very same frontend with even no real spool dir, you might have an erroneous proxyservers option defined in your frontend's imapd.conf. Take it away. :-) 2. On a clustered environment where spools are mounted only on certain nodes running the respective Cyrus instance, calling cyr_df makes no sense. It is only a wrapper of some kind to df and can be called locally where the spool is mounted. Running Cyrus 2.3.16 (Invoca RPM) on a CentOS 5.4 cluster, mupdate_config: standard. -- Jukka Huhta University of Helsinki Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: cyrus replication and RENAME problem
On Tue, 1 Jun 2010, Bron Gondwana wrote: > On Tue, Jun 01, 2010 at 11:14:02AM +0200, Rudy Gevaert wrote: > > On 05/31/2010 03:31 PM, Bron Gondwana wrote: > > > On Mon, May 31, 2010 at 12:58:57PM +0200, Rudy Gevaert wrote: > > >>> Renaming forth and back is a way, but not a really good solution to this > > >>> problem. > > >> > > >> Hi Mark, > > >> > > >> Have you been able to fix this? It seems a bug to me. > > > > > > Sorry, yes - it's a bug. It will be fixed in 2.4 (as in, I've already > > > come across it while rewriting the sync protocol and fixed it) - I'm not > > > sure there's heaps of value backporting it to 2.3 right now. > > > > > > Another workaround is just to rename the folder on the replica as well. > > > Presumably the admin is doing this, and it's a fairly rare case... > > > > > > Bron ( yes, workaround suck... ) > > > > > > Thanks for replying. > > > > How are other people doing this who are using partitions and replication? > > (we don't use partitions) > > Is it common to rename mailboxes across partitions once they're created? Well, I'm planning to move mailboxes to other spools for balancing the disk usage after adding new spools. Does this bug affect XFER as well? -Jukka Huhta, Univ. of Helsinki Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: cyrus replication and RENAME problem
On Mon, 31 May 2010, Bron Gondwana wrote: > On Mon, May 31, 2010 at 12:58:57PM +0200, Rudy Gevaert wrote: > > > Renaming forth and back is a way, but not a really good solution to this > > > problem. > > > > Hi Mark, > > > > Have you been able to fix this? It seems a bug to me. > > Sorry, yes - it's a bug. It will be fixed in 2.4 (as in, I've already > come across it while rewriting the sync protocol and fixed it) - I'm not > sure there's heaps of value backporting it to 2.3 right now. Oh. I'm probably facing troubles because of this bug - I need to get ~25k user mailboxes moved to different partitions quite soon. When is the 2.4 release expected and what about backwards compatibility? > Another workaround is just to rename the folder on the replica as well. > Presumably the admin is doing this, and it's a fairly rare case... Currently I don't have any IMAP frontends on the replica, so the only interface to the replica spools is the sync_client/sync_server (if you don't count editing the databases by hand). Probably putting up one is still a better workaround than really renaming mailboxes back and forth. Issuing a "renm user.foo user.foo another-backend!another-partition" command on a frontend seems to move user.foo also on the replica, so if it was possible to change also the backend, this would probably do the trick? -Jukka Huhta Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: cyrus murder serverlist ?
On Mon, 30 Aug 2010, Andre Felipe Machado wrote: > I already tried to setup parameters for creating mailboxes on the backend with > most free available space when no partition is specified, following imapd.conf > man page. > The source code uses some conditions to achieve this, like for example: > IMAP_ENUM_MUPDATE_CONFIG_STANDARD (== 0 as enumerated) > IMAPOPT_PROXYSERVERS or IMAPOPT_DEFAULTSERVER > imapd_userisadmin || imapd_userisproxyadmin > > But despite configuring them, the frontend still writes locally... I managed to do it somehow some time ago. First I had an erroneous proxyservers option in the frontend imapd.conf. After having that removed it started to work. Almost. The algorithm just miscalculated the freespace response received from the backend servers and gave somewhat random results. I reported the bug(?) here and in the bugzilla (#3225). No one reacted. So - I'm not sure what's the situation with this feature. I'm about to write my own script for this purpose, finding the most suitable backend and partition. And BTW, it would be nice to have the replication working when moving users across partitions... -Jukka Huhta Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Cyrus IMAPd 2.4.0 Released
On Wed, 13 Oct 2010, Simon Matter wrote: > Of course I'll update our RHEL/CentOS RPMs but it may take a bit more time > than the usual hours or days because of the many changes in the new > release. Some of the stuff which has been done in the RPM automagically - > like converting databases on startup - has now been integrated in the main > code and I have to look at things in detail. > > While we are at it, I have your 0012-Clean-Shutdown.patch in the RPM, from > what I see in the changelogs this has not been integrated with 2.4, right? > If yes, do you still use the patch in your own version, could you make > this patch for 2.4 available somehow? > > The other thing I'm wondering now is how to go on with the autocreate > feature. I'm not sure I'll be able to recreate the patches for 2.4 and I > don't know if the nice people from University of Athens will be going to > do it. Hm, I won't be happy to release a new RPM with this feature > missing. Any updates concerning these issues? I suppose there are many of us who would rather not upgrade an RPM packaged software to one without packaging. Anyway, thank you for your efforts. --Jukka Huhta Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Problem listing folders and subfolders
In Cyrus 2.3.16 (and earlier, don't know about 2.4 yet), there seems to be a problem listing subfolders in a following case. When a user has folders named like this: * LIST (\HasNoChildren) "." "INBOX.subfolder" * LIST (\HasNoChildren) "." "INBOX.subfolder 2" * LIST (\HasNoChildren) "." "INBOX.subfolder.subsub1" * LIST (\HasNoChildren) "." "INBOX.subfolder.subsub2" The space character (in "subfolder 2") seems to be sorted before dot (hierarchy separator) so that Cyrus thinks that "subfolder" has no children. After deleting/renaming "subfolder 2" the listing works as expected: * LIST (\HasChildren) "." "INBOX.subfolder" * LIST (\HasNoChildren) "." "INBOX.subfolder.subsub1" * LIST (\HasNoChildren) "." "INBOX.subfolder.subsub2" In some mail clients, namely IMP, the second level subfolders disappear totally when Cyrus declares that the parent folder "HasNoChildren". We have several reports from confused users who have "lost" their subfolders mysteriously. I didn't find any earlier discussions about this, but can anyone confirm/fix the issue? -Jukka Huhta Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Cyrus 2.4.6: RENAME/XFER problems
:47:32 m2cn3t im/mupdate[16394]: accepted connection Jan 18 12:47:32 m2cn3t im/mupdate[16394]: login: lcluster.mappi.helsinki.fi [...] User logged in Jan 18 12:47:32 m2cn3t m2v1t/imapm2v1t[9845]: Could not move mailbox: user.jtest400, MUPDATE DEACTIVATE failed Jan 18 12:47:32 m2cn3t m2v1t/imapm2v1t[9845]: MUPDATE: lost connection, retrying Jan 18 12:47:32 m2cn3t im/mupdate[16394]: New worker thread started, for a total of 7 Jan 18 12:47:32 m2cn3t im/mupdate[16394]: accepted connection Jan 18 12:47:32 m2cn3t im/mupdate[16394]: login: lcluster.mappi.helsinki.fi [...] User logged in Jan 18 12:47:32 m2cn3t m2v1t/imapm2v1t[9845]: Could not back out mupdate during move of user.jtest400 (bad parameters to function) -- Jukka Huhta University of Helsinki Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: Cyrus 2.4.6: RENAME/XFER problems
On Tue, 18 Jan 2011, Jukka Huhta wrote: > In 2.4.6, every renm/xfer command I can come up with in cyradm fails > somehow. ...except for the obvious ones, which are working as expected: m2v3t.mappi.helsinki.fi> xfer user.jtest400 m2v2t.mappi.helsinki.fi m2v2t-b m2v2t.mappi.helsinki.fi> renm user.jtest400 user.jtest400 m2v3t.mappi.helsinki.fi!m2v3t-b Anyway, I still haven't found a way to move a user to different spool partition on the same backend. Not a supported operation? -- Jukka Huhta University of Helsinki Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: Cyrus 2.4.6: RENAME/XFER problems
On Wed, 19 Jan 2011, Andrew Morgan wrote: > I'm running 2.3.16. I use: > > RENAME $mailbox $mailbox $partition Yes, but the change won't get replicated in 2.3 (see http://www.mail-archive.com/info-cyrus@lists.andrew.cmu.edu/msg39532.html) which is why I wanted to upgrade to 2.4 in the first place, to avoid ugly workarounds. -- Jukka Huhta Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: Cyrus 2.4.6: RENAME/XFER problems
On Wed, 19 Jan 2011, Andrew Morgan wrote: > I haven't tried to upgrade to 2.4 yet. What is the problem? m2v3t.mappi.helsinki.fi> info user.jtest400 partition: m2v3t-b [...] m2v3t.mappi.helsinki.fi> rename user.jtest400 user.jtest400 m2v3t renamemailbox: Mailbox is locked (BTW, m2v3t here matches to both hostname and partition. Not good. But the symptom is anyway the same if I want to move from m2v3t to m2v3t-b. Why locked?) m2v3t.mappi.helsinki.fi> rename user.jtest400 user.jtest400 m2v2t.mappi.helsinki.fi renamemailbox: The remote Server(s) denied the operation Log entries: Jan 20 10:14:54 m2cn1t m2v2t/imap[24709]: kick_mupdate: can't connect to target: No such file or directory Jan 20 10:14:54 m2cn1t m2v2t/imap[24709]: IOERROR: Mailbox name too long (user.jtest400) Jan 20 10:14:54 m2cn1t m2v3t/imap[18230]: Could not move mailbox: user.jtest400, LOCALCREATE failed m2v3t.mappi.helsinki.fi> rename user.jtest400 user.jtest400 m2v2t.mappi.helsinki.fi!m2v2t #ok Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: Cyrus 2.4.6: RENAME/XFER problems
On Thu, 20 Jan 2011, Bron Gondwana wrote: > Is this bugzilla'd yet? "Bug 3391 has been added to the database" Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
2.3's future?
I filed a bug 3397 (replication & partitions), also reported in http://www.mail-archive.com/info-cyrus@lists.andrew.cmu.edu/msg39940.html. What are the odds to have it fixed in 2.3 or will it just be closed with WONTFIX? If we don't count these few replication related bugs, 2.3 appears to be fairly stable compared to 2.4, IMHO. I'm still waiting for 2.4 to grow up a bit before upgrading our production servers, even though I may be overly cautious. -Jukka Huhta Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
