Thank you,
I'd go with cyrus. It scales a lot better than UW IMAP from what I've seen.
--
/Ian D
i...@assv.net
It all depends upon the site. The communities for UW and Cyrus have very
little overlap. In order for you to make an intelligent decision, I
recommend that you get a copy of "Managing IMAP", by Dianna Mullet & Kevin
Mullet, published by O'Reilly, ISBN 0-596-00012-X.
On the crudest measures of comparision:
Cyrus certainly performs better than a UW server in its default "full UNIX
compatibility" configuration. Cyrus makes not attempt to be compatible
with existing UNIX mail stores; it has its own.
UW is the clear winner on ease of configuration; it literally is plug and
play and it builds on almost any system (including truly ancient UNIX
environments). You don't have to configure anything, and the
documentation goes to some effort to discourage you from any configuration
away from the default until you've had a chance to get some experience
with it.
UW is also the clear winner on ease of administration. There is no
administration specific to UW; it inherits the UNIX administration.
On the other hand, Cyrus is the clear winner on administration power.
Just about everything you may want to tweak on IMAP administration is
tweakable with Cyrus. In fact, you have to tweak it.
I recommend that you start with the UW server first, since it is much more
of a generalist and involves much less work. You can switch to Cyrus
later at relatively low cost if you find that UW doesn't suit your needs.
If you go the other way, and find that Cyrus requires too much of your
time, you would have expended much more effort.
-- Mark --
http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
I heartily agree with Mark's recommendation. That's an excellent book.
Just as another data point, I run a *very* small site (only a handful of
users) and started with UW. It was easy to get running, and performance was
fine (I think I was using the mbx mail format).
However, if you have users with existing mail folder structures that need to
transfer over, be aware that the mbx format, though fast, has a limitation --
it doesn't support nested folders. This caused a real problem with one of my
users (my wife, so I need to keep her happy!) who had a fairly complex
existing directory structure in her MS Outlook mailbag. I was trying to
move her mail from the mailbag to the IMAP server (which Outlook makes
easy; you just drop and drag the folders), but the pain of digging out dozens
of deeply nested folders was too much to bear, and I found it easier to
convert to Cyrus which has the combination of good performance for large
folders (my personal setup) and support for nested folders.
There's one other downside to many of the Unix based storage schemes that
Outlook users may not care fore -- the Unix reserved characters can't be used
in folder names. In particular, my wife had lots of folders with dates in
"MM/DD/YY" format, and I had to rename those using "-" instead of "/".
Periods are also disallowed characters, so European date formats don't work,
either.
But once we got past those points, Cyrus has been working very well with both
my Mulberry and Pine clients, and my other users' Outlook ones. UW would have
been just fine if we hadn't had the existing mailbag structure issues to deal
with. In the end, it might have been less time-consuming to just redo my
wife's folders to a structure mbx could handle, but I wouldn't have learned
nearly as much :-).
John Ackermann
j...@no.febo.spam.com (you know what to do)
I've written some about naming mailboxes in my my Procmail Quick
Start in this section:
<http://www.ii.com/internet/robots/procmail/qs/#mailboxFormats>
But I'd like to update it to include more information about
characters (e.g. slash (/) and dot (.)) and names (e.g. "inbox")
that are good to avoid in a mailbox name. I'd appreciate any help
coming up with a list of characters that are unacceptable in
mailbox names in all the the flavors of IMAP servers and
platforms. As John described above, it's useful to avoid these
characters on all platforms so you won't run into problems if you
switch.
Thanks!
^X,
Nancy
(also a Mulberry and Pine user)
REFERENCE:
The message I'm replying to -- and this entire thread & group --
may be available at
<http://groups.google.com/groups?as_umsgid=%3Cr0d4i...@209.115.70.194%3E>
--
Nancy McGough <http://www.ii.com/> Infinite Ink
= Sent via Pine 4.39.99: IMAP, NNTP & ESMTP for Unix/Win/Mac OS X =
I've written some about mailbox names in my Procmail Quick Start
in the section called Use Naming and Formatting Styles, which is
here:
<http://www.ii.com/internet/robots/procmail/qs/#style>
But I'd like to update it to include more information about
characters, e.g. slash (/) and dot (.), and names, e.g. inbox,
that are good to avoid in a mailbox name. I'd appreciate any help
coming up with a list of characters that are unacceptable in a
mailbox name in some IMAP server or on some platform. As John
described above, it's useful to avoid these characters on all
platforms so you won't run into problems if you move a mailbox
from one system to another.
Thanks!
^X,
Nancy
In article <Pine.WNT.4.39.99.0107071026001.-4022981-100000@no>,
Nancy McGough <nm-this-addr...@no.sp.am> writes:
> But I'd like to update it to include more information about
> characters (e.g. slash (/) and dot (.)) and names (e.g. "inbox")
> that are good to avoid in a mailbox name. I'd appreciate any help
I would recommend avoiding (/) (.) (\) (#) and (:). I'd also avoid quotes,
apostrophes, parenthesis, brackets, and braces. You also should not use *
and %, since they are reserved specials for LIST.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: http://www.geocities.com/SiliconValley/Peaks/5799/GPGKEY.txt
iD8DBQE7SPri+3BFaxHnGY0RAnoxAJ4yGqtbuTBNZjCalAP6KMT5wntv/wCbBk2q
dnN+HeiXyA2CIrJUCOEsL9A=
=FVf1
-----END PGP SIGNATURE-----
Thanks Sam! I just updated my Procmail Quick Start so that it
suggests people don't use those characters in mailbox names. I
also give a link to your page and googlicized version of your
message. If anyone has any feedback on this:
<http://www.ii.com/internet/robots/procmail/qs/#style>
or any other part of the Procmail Quick Start, which makes quite
a few references to IMAP, please let me know.
Thanks,
^X,
Nancy
REFERENCE:
The message I'm replying to -- and this entire thread & group --
may be available at
<http://groups.google.com/groups?as_umsgid=%3Ccourier.3B4...@ny.email-scan.com%3E>
I am also considering switching to Cyrus server from the one comes with
RH 7.1 because of some problems with Kerberos authetication.
In addition to scalability, can you tell me about this (support of Kerberos
and its configuration), too?
Thanks in advance.
Joseph Kim
k...@stanford.edu
> Hi,
>
> I am also considering switching to Cyrus server from the one comes
> with RH 7.1 because of some problems with Kerberos authetication.
> In addition to scalability, can you tell me about this (support of
> Kerberos and its configuration), too?
I don't know anything about kerberos and how things interact with it,
but CMU is a Kerberos stronghold, and Cyrus has support for it.
--
/Ian D
i...@assv.net
If you build imapd to use GSSAPI authentication you can also do password
authentication against Kerberos without having to go through PAM. This is
PASSWDTYPE=gss (as opposed to PASSWDTYPE=pam).
I'm moving from UW IMAP to Cyrus.
Outlook is killing me as a client. I know the multiple connection issue will
go away, but my users are having terrible trouble accessing their accounts.
Admittedly, it does not help when many users have 100-200 meg folders
systems.
First, I would like to know how responsive your Outlook clients are. I'm
using Outlook 2000. If you've used UW IMAP, I would love to know if my
future change will improve my current performance issues.
I don't think I can use Pine in my office given its pretty basic interface.
I understand that it is considered the best IMAP client. I'm just started
testing Mulberry. I've noticed very high CPU utilization rates and I'm not
sure if this is typical. Outlook, on the other hand, freezes up the computer
(NT 4.0)and uses zero CPU.
I'm very curious to know if your users find it an easy transition between
Outlook and Mulberry. Also, is there a reason you support three clients?
Thank you,
==Thane
>John,
>
>I'm moving from UW IMAP to Cyrus.
>
>Outlook is killing me as a client. I know the multiple connection issue will
>go away, but my users are having terrible trouble accessing their accounts.
>Admittedly, it does not help when many users have 100-200 meg folders
>systems.
What format are your mail folders? If you are using unix style
mailboxes, you will get very poor performance when the files get big.
mbx is much better.
Gareth
Unfortunately, it is a pain in the neck to get mbx folders. UW-IMAP
defaults to Unix mbox folders on Unix-ish machines, and the
documentation gives stern warnings against using a configuration file to
change. Moreover Sendmail, Postfix, procmail etc do not deliver mbx and
will need coaxing. I tried to set up a new UW-IMAP system with mbx, but
decided that with all the work involved (like compiling c-client and
imap-utils to get tmail) it was easier to just install the cyrus-imapd
RPM from Red Hat's Powertools CD.
Chris
>On Wed, 01 Aug 2001 12:31:55 GMT, Gareth Jones <gar...@uberdog.net> wrote:
>>tter...@hotmail.com (Thane) wrote:
>>>I'm moving from UW IMAP to Cyrus.
>>>
>>>Outlook is killing me as a client. I know the multiple connection issue will
>>>go away, but my users are having terrible trouble accessing their accounts.
>>>Admittedly, it does not help when many users have 100-200 meg folders
>>>systems.
>>
>>What format are your mail folders? If you are using unix style
>>mailboxes, you will get very poor performance when the files get big.
>>mbx is much better.
>
>Unfortunately, it is a pain in the neck to get mbx folders. UW-IMAP
>defaults to Unix mbox folders on Unix-ish machines, and the
>documentation gives stern warnings against using a configuration file to
>change.
I'm not sure which documentation you mean. You can change the default
format quite easily by editing the makefile (IIRC, replace the lines
containing CREATEPROTO and EMPTYPROTO in the file
src/osdep/unix/Makefile with:
CREATEPROTO=mbxproto
EMPTYPROTO=mbxproto
then compile.
>Moreover Sendmail, Postfix, procmail etc do not deliver mbx and
>will need coaxing.
I don't know about the others, but sendmail doesn't deliver to local
mailboxes at all - it simply calls the local delivery agent. In this
case you need to use a delivery agent that understands mbx.
Gareth
>
>I'm not sure which documentation you mean. You can change the default
>format quite easily by editing the makefile (IIRC, replace the lines
>containing CREATEPROTO and EMPTYPROTO in the file
>src/osdep/unix/Makefile with:
>CREATEPROTO=mbxproto
>EMPTYPROTO=mbxproto
>
>then compile.
>
The document referred to is the document describing the /etc/c-client.cf
file. It is found among the documentations file in the imapd and/or
c-client source tree (or was found if it has been removed).
Villy
Ah, you are from the old school ("build everything from scratch"). Due
to the number of library dependencies (in this case SSL, PAM and
Kerberos) in today's apps, I prefer to install precompiled RPMs from the
distribution CD. The best thing about wu-imapd is that there is nothing
to configure. The unfortunate part about wu-imapd is that there is
nothing to configure. The file I was talking about was imaprc.txt, which
as you probably know warns against using the configuration file. The
"approved" way to enable mbx folders is to build from source. However,
it was much easier to install the cyrus-imapd RPM instead.
>>Moreover Sendmail, Postfix, procmail etc do not deliver mbx and
>>will need coaxing.
>
>I don't know about the others, but sendmail doesn't deliver to local
>mailboxes at all - it simply calls the local delivery agent. In this
>case you need to use a delivery agent that understands mbx.
Of course, no such delivery agent comes in an RPM, so one would have to
build from source. Yuck. :-)
Chris