Cyrus IMAP Presentation

[Rob Siemborski]

On Sat, 14 Sep 2002 adam at morrison-ind.com wrote:

> I've created a presentation about Cyrus IMAPd that I will be showing to the
> local LUG in a couple of weeks.  I'd appreciate it if some Cyrus masters would
> take a look at it and see if I've gotten anything wrong.

Some of these may be a bit picky, but they're things I noticed.

(Slide 5)
I beleive there are Debian Packages, put together by Henrique de Moraes
Holschuh <hmh at debian.org>.

(Slide 6)
"prefork" keeps *atleast* that number of processes standing by.  Processes
will be reused as they become available (and they expire after they've
been waiting around for a while doing nothing)

(Slide 8)
The mailbox hierarchy does not have to work the way you describe (see also
altnamespace and unixhierarchysep)

(Slide 11)
Technically, you can have administrative accounts other than
"cyrus".  And you can change the access right required to delete folders
with the deleteright flag.

(Slide 12)
Your information regarding postuser is wrong.  You specify postuser to
be "boards" but then send a message to "bb+service".  Even then, the
example you give (bb+service) delivers to the mailbox "service" and not
boards.service.

(Slide 15)
- I think you mean "Cyrus IMAP uses Cyrus SASL version 2 to proces all
authentication"
- Your catagorization of Kerberos IV as a plaintext mechanism is
confusing.  Yes, you can verify plaintext Kerberos IV passwords.  You can
also verify Kerberos V passwords.  Of course, you should avoid doing this
as much as possible and just use the KERBEROS_IV and GSSAPI SASL
mechanisms if you can.
- Along the same lines, "GSSAPI" is more correct than Kerberos V.
- SASLdb is not the only way of storing shared secrets, and there are
other mechanisms that can use them (SRP, OTP)

(Slide 16)
- "-n 5" is probably low for a reasonably high traffic site.

(Slide 29)
- Managing IMAP is well out of date, and probably is more confusing than
helpful.

> ftp://kalamazoolinux.org/pub/pdf/Cyrus.pdf
>
> And I have a couple of questions that the docs just didn't seem to fill in:
>
> 1. Does Cyrus IMAP has a logo?

Nope.

> 2. What is the best way to backup the mail store?  Just tar?  Even while master
> is running?

Have a filesystem capable of snapshots, snapshot the filesystem(s) at as
close to the same time as you can, and backup the snapshot(s).

Just TARing the filesystem will mostly work, though you may get
inconsistant results (which may appear as corrupted mailboxes, or
a mailbox list which doesn't match the disk).

> 3. When, pragmatically, does someone want to use IMAP IDLE?  I'm a little lost
> on that one.

Basically, when you don't want to bother sending NOOPs.  Technically, IDLE
was designed for clients who wanted to poll very often, but in practice
having a short imapidlepoll time would create just as much load as NOOPing
that often.

> 4. SIEVE seems to be poorly documented.  Any link?

The RFC's are pretty complete.  Take a look at doc/specs.html

> 5. Are there any benchmarks comparing Cyrus, UW, and Courier?  I know all
> benchmark numbers are squishy,  but some types really want to see them.  So far,
> since I've switched from UW to Cyrus, Cyrus seems to leave UW in the dust.

I am not explicitly aware of any benchmarks comparing the two (three).
Though I can completely believe your assertation that Cyrus is faster than
UW, just because of the fact that our mailstore is optimized for IMAP and
UW tries to be compatible with traditional unix mailstores.  I don't know
anything about Cyrus vs. Courier.

However, technicaly, Courier isn't an IMAP server, since it is
noncompliant in a variety of ways, and its author refuses to change it,
though I don't think any of its incompatibilities would result in a
performance loss (or gain).

> 6. Is Mulberry the only mail client to support adjusting the ACLs of mailboxes,
> etc... (It looks like it does from screenshots I've seen).  If so, are the
> protocol extensions required to do this documented?

cyradm does it (Surprise! it's an IMAP client ;).  The protocol extentions
are documented in RFC 2086.

-Rob

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456
Research Systems Programmer * /usr/contributed Gatekeeper