Looks interesting, but....

[goo0h]

After having used Cyrus for many, many years in a production environment with overall great success, I have to admit at being very anxious with the idea of dumping that (and migrating all the users) over to what is in all honesty is an untried implementation. We also make extensive use of shared ("public") folders and complex folder ACLs. I have a hard time seeing it being practical to dump that, even for what appears to be a rather nice client. (I'm at least impressed to see that apparently Zimbra supports Sieve. Though, would that only be one script per user?)

I'm assuming the email messages are stored in MySQL, right? Do folks have any idea of the scalability for such an arrangement?

What about the recovery of messages/folders? One thing I've always liked about Cyrus is that headers are cached, but the messages remain in single files. While this might be simplistic, it sure makes recovery of messages/folders immensely trivial. How does one go about recovering messages when they're in a db?

[KevinH]

We actually only store meta data in the database. The messages are stored in MIME files in on the file system. Take a look at this doc for more details.

http://www.zimbra.com/downloads/zimb...l_overview.pdf

-kevin

[goo0h]

Originally Posted by KevinH

We actually only store meta data in the database. The messages are stored in MIME files in on the file system.

Interesting.... I'll give it a read. Thanks.

[HankFay]

Visual SourceSafe, the Microsoft source control tool, has used, still uses, one file per file version, which is equivalent to one file per message as Zimbra is using. With low total numbers it works OK; it does not scale. I see no reason to expect a different result here, which is unfortunate, because with the addition of a few other tools common to Notes or Groove, this is a dynamite product.

[KevinH]

Visual SourceSafe, the Microsoft source control tool, has used, still uses, one file per file version, which is equivalent to one file per message as Zimbra is using. With low total numbers it works OK; it does not scale. I see no reason to expect a different result here, which is unfortunate, because with the addition of a few other tools common to Notes or Groove, this is a dynamite product.

The filesystem access patterns of a source control system and a mime message store are quite different. Also Visual Source safe only runs on the MS Windows file system. In our case we use the Linux Ext3 file system which for our uses performs very well even with large mailboxes. The messages(files) are for the most part write once; read many. All the expensive searches are performed against the metadata in MySQL or the indexes of Lucene; both of which are designed for these types of queries.

Regardless if/when you install our application and see things we've missed with regard to performance we'd be willing to review your test case. Our tests and trials have all yielded impressive performance but we are always looking for ways to improve.

[HankFay]

Using the metadata in a real database is a fish of another color, a color I hadn't caught. Thanks.

[abo]

Ok, I'm impressed, but I'm also pretty happy with Cyrus IMAPd. (Also, regardless of the merits of any particular IMAP implementation, our mail store is so large that migrating it is something we would very much like to avoid.)

So, I'm looking for an estimate on how difficult it would be to add a IMAP backend to Zimbra. The IMAP backend would probably have to cache a lot of data to keep things fast, but hopefully, it would be possible. Any thought?

[abo]

Uh, ok that previous post, while somewhat on topic in this thread, would be more on topic in the Devel forums.

[KevinH]

Originally Posted by abo

Ok, I'm impressed, but I'm also pretty happy with Cyrus IMAPd. (Also, regardless of the merits of any particular IMAP implementation, our mail store is so large that migrating it is something we would very much like to avoid.)

So, I'm looking for an estimate on how difficult it would be to add a IMAP backend to Zimbra. The IMAP backend would probably have to cache a lot of data to keep things fast, but hopefully, it would be possible. Any thought?

I think your next post meant you saw that we do have IMAP and POP support. But just to be sure. I'll say it

We support IMAP/POP in additon to the AJAX web client.

[abo]

Originally Posted by KevinH

We support IMAP/POP in additon to the AJAX web client.

Well, actually, what I'm after is an IMAP client inside Zimbra, so that I can keep the mail on the existing IMAP server but still use the Zimbra AJAX web client.

So, why not move the mail into Zimbra? This is going to sound like I'm complaining, but I assure you I'm not. I'm just trying to explain. Perhaps if we like Zimbra enough we could dedicate resources to developing the extensions we need, in the spirit of Open Source.

With many thousands of users and houndreds of gigabytes of mail, moving would be a big deal. First, there would need to be lots of evaluation and proving that it all works and is the right solution for us. Then, moving it all a once would probably be impossible, the downtime while the store is in transit would be too long. So we'd have to move it one mailbox at a time, which means users would at the right moment need to change their settings to use the new server since the new server couldn't use the hostname of the old server. Possibly, some kind of proxy could be put in place to hide the fact that there are multiple server, but it still a big project.

Also, does it have all the features we need from an IMAP server? Like scalability: Cyrus has Murder, a proxy that allow the mail store to be split up into several machines. That's something we're considering using. Another thing we need is Kerberos support. I think I saw something about Zimbra using Cyrus SASL. In that case perhaps single-sign-on using Kerberos already works.

So, keeping the mail on our trusty old Cyrus IMAPd, but using Zimbra as a web mail client and as a collab suite would probably work very well for us. It'd give us a what we need while at the same time being simple to implement (after the code has been written that is) and require no changes to the existing infrastructure.