Say you have an exclusive ticket to get into a private party. You go to the party, hand over the ticket, and you get in. The ticket authorized you to get in (though had you lost the ticket, anyone who found it would also have been authorized to get into the party).
Ok, now, next week, you get another ticket to get into another private party, but the ticket is only good to let you into the party. You go to the party and show the ticket, and the person at the door says "prove to me you're the person whose name is on this party ticket". Your proof is authentication, the ticket is authorization.
The authentication in the above example depends upon some authority trusted by the person at the door. For example, you may have shown a passport or a drivers license. The person at the door would have to trust that the passport or license was real and accurate (though even if it were, you might coincidentally have the same name as the name on the ticket, but be a different person, hence we have not 100% authenticated you if only your name was on the ticket; e.g. a picture on the ticket would have been better).
When you log in to your email with a user name and password, you are providing your authentication. Think of your name/password as an identification of who you are - it is identifying that it is _you_ who is using the name/password. Now, what you are allowed to do once you are authenticated to the server is governed by your authorization. For example bob may only be authorized to see his INBOX, while the 'cyrus' user can list all the mailboxes on the server, and change their ACLs.
Cyrus was designed to use a local filesystem with Unix semantics and a working mmap()/write() combination. AFS doesn't provide these semantics so won't work correctly.
The first way allows delviery to a subfolder of a specific user's INBOX. This is done via an address of the form: username+mailfolder@domain, which will deliver to the user's INBOX.mailfolder folder (or altnamespace equivalent). This submailbox must allow the posting user the 'p' right (generally, this means 'anyone' must have the 'p' right), otherwise the message will just be filed into the user's INBOX.
The second way is to form an address like [postuser]+mailfolder@domain. This will deliver into the mailbox 'mailfolder'. [postuser] is the string specified in the imapd.conf option of the same name, and may be the empty string. As before, the posting user will need to have the 'p' right on the mailbox.
For both methods, if 'mailfolder' is more than one level deep, you will need to conform to the hierarchy separator appropriate to your site.
A: If you're using Berkeley DB 3.0.55, try installing some patches to Berkeley DB available from http://www.sleepycat.com/update/3.0.55/patch.3.0.55.html.
A: Make sure /etc/sasldb2 is readable by the Cyrus user.
A: Make sure that the saslauthd daemon is running (you'll want to start it when the system boots). imapd is unable to connect to saslauthd if the following message appears in the logs:
Dec 6 12:58:57 mail3.andrew.cmu.edu imapd[1297]: cannot connect to saslauthd server
Make sure that saslauthd is running and that the cyrus user can access the unix domain socket (defaults to /var/run/mux).
A: These messages look like
Jan 14 13:46:24 grant ctl_deliver[9060]: duplicate_prune: opening /var/imap/deliverdb/deliver-x.db: No such file or directory Jan 14 13:46:24 grant ctl_deliver[9060]: duplicate_prune: opening /var/imap/deliverdb/deliver-y.db: No such file or directory Jan 14 13:46:24 grant ctl_deliver[9060]: duplicate_prune: opening /var/imap/deliverdb/deliver-z.db: No such file or directory
These messages are normal; one file is maintained for each user beginning with "x", "y", "z", etc. If you're first starting or you have no users beginning with these letters, these messages are completely normal and can be ignored.
A: Remove all imap, pop, lmtp and sieve lines from [x]inetd.conf and restart [x]inetd. Cyrus is run out of its own "master" process.
A: Specify the different certs using the appropriate options in imapd.conf. Read imapd.conf(5) for details.
A: Disable TLS for the kpop service. Either set tls_pop3_cert_file to disabled in imapd.conf (which will also disable SSL/TLS for pop3), or use a separate config file for kpop. For example, change the kpop service in cyrus.conf to something like:
kpop cmd="pop3d -k -C /etc/kpopd.conf" listen="kpop"
then copy /etc/imapd.conf to /etc/kpopd.conf and remove the tls_* options.
A: First, complain to QUALCOMM because their STARTTLS implementation is broken. Eudora doesn't support TLSv1 (per RFC2246) and Cyrus requires it. If you really need this before it is fixed in Eudora, remove or comment out the following lines in tls.c:
if (tlsonly) {
off |= SSL_OP_NO_SSLv2;
off |= SSL_OP_NO_SSLv3;
}
Sep 11 17:23:55 ogg lmtpd[773]: DBERROR db3: 16 lockers Sep 11 17:23:55 ogg lmtpd[1409]: DBERROR db3: 17 lockers Sep 11 17:23:56 ogg lmtpd[1508]: DBERROR db3: 9 lockers Sep 11 17:23:56 ogg lmtpd[776]: DBERROR db3: 9 lockersWhat's wrong?
A: Nothing is wrong. These messages are logged whenever Berkeley db encounters lock contention, but isn't necessarily a problem by themselves. This is especially likely when you have an empty or small duplicate delivery database and are receiving a large volume of e-mail.
Berkeley db 4.0 has a bug where the number of lockers isn't decremented properly, causing this number to be unreliable.
A: 8-bit characters are illegal in message headers. Following the principal of "be liberal in what you accept, and strict in what you send" cyrus converts them to Xs. (Without a character set, having the 8-bit characters replaced with Xs is just as good as having them be any other 8-bit character, especially for sorting and searching). Alternatively, you can set "reject8bit: t" in imapd.conf to reject the messages outright. It might also be reasonable for cyrus to support the use of a default character set, however thus far no one has done the work to do so (it would also involve QP-encoding the corrupted headers).
A: Trash folders, as they are commonly implemented (as an actual IMAP mailbox), do not fit the IMAP delete/expunge model very well. In fact, naive client implementations will get stuck in a situation where they cannot delete a message from a mailbox because they try to COPY it to the trash folder before deleting the message. This operation will fail due to the mailbox being over quota. This is separate from the fact that a specific mailbox name is not interoperable between clients (one might call it 'trash', another 'Trash', another 'Recycle Bin', etc)
Given the lack of protocol support for a trash folder, this is mostly a quality-of-implementation issue on the client side. There are a few options here:
A: Not really a Cyrus IMAPd question, this can be fixed by just removing the SASL plugins from where Cyrus SASL installed them (if no other applications require them), or by using the sasl_mech_list imapd.conf option to list only the mechanisms that you require.