Recently in Cyrus IMAP Category

Obsolete things can be nice. They can be useful. These "cmusaslsecret"-Thingies are.
But let's start from the beginning. You may however start to play with them!

You are using Cyrus SASL for authentification purposes? Supposedly with the Cyrus IMAP server or Postfix (the two major applications using Cyrus SASL)? Then you'll know the problem: You may use saslauthd(8) to connect to an authentication database as Unix PAM or LDAP. Problem: You will only be able to use plaintext logins. Why?

If using saslauthd, the SASL-enabled server gets the password given by the user/client, and asks saslauthd whether it is correct or not.

Plaintext authentication can be sufficient when using it with SSL/TLS. In IMAP environments this may be a good solution if all mail clients can be configured in that way. With SMTP you will have a problem. Many Mailservers being able to initiate authenticated outgoing SMTP connections do not use SSL/TLS. Many of them want to use CRAM-MD5 as it is defined in many standard drafts.

[Update] Version 1.2.1 now accesses any attribute requested by SASL, so the use of cmusaslsecret* is possible. In this version the parameter "gl_attribute" has been omitted.

Downloadlinks in this article have been corrected to get the 1.2.1 version.


NOOOOO! Don't talk about saslauthd(8). Customer wanted CRAM-MD5 and DIGEST-MD5 as authentication mechanism for his Postfix authenticated SMTP service. No, not just PLAIN. So saslauthd is out of the game.

Customer has a "mail password" in cleartext in his LDAP structure [Update: he is using cmusaslsecretCRAM-MD5 now] - especially for this kind of thing. Is it possible to use Postfix with that?

First - this is not a postfix issue. Customer had Postfix linked with cyrus sasl. Not a bad idea - but to use these LDAP entries you have to have an appropriate cyrus sasl auxprop. Why?

CRAM-MD5 and DIGEST-MD5 are shared secret algorithms. The server MUST know the cleartext password or the mechanisms' secrets in order to validate the answer sent by the client.

At the first look, I saw a "ldapdb" auxprop plugin which should just do that - and it failed because we did not have a SASL enabled OpenLDAP so ldapdb authentication failed. "*cmusaslsecretCRAM-MD5" (in the case of CRAM-MD5, replace it with DIGEST-MD5 when using DIGEST-MD5) and userPassword are requested from the sasl auxprop.

So here it goes - I had to write my own ldap auxprop. You may use it if you want. I will expain the way to write SASL auxprops in the next days to come, but for now - here is the source.

Use syslogd(8) to get debug messages (loglevel debug, facility auth).

Just a side note:

We are using ZFS across two SAN mirror pairs for our production mailserver. It is running Cyrus IMAP with 14000 users and 50000 mailboxes. The zpool has 8 Terabytes and the system experienced some latencies when accessing data on the zpools.

The first problem was easy to resolve but still we had IMAP SELECT times greater 0,5 seconds on some accesses.

The machine was doing approx 2000 random read accesses per second (we have approx 1000 concurrent IMAP users including our webmail application which is heavily using IMAP commands).

The first step was to put more RAM for the ARC cache in the machine, which resulted in 100-200 random read accesses per second. Cyrus metadata files of logged in users are now mainly in RAM.

The second step was to disable the prefetching algorithm. I put that in /etc/system:

set zfs:zfs_prefetch_disable=1

And - hooray - SELECT times are under 0,1 seconds. The prefetch method seems not to be optimized for a highly random i/o environment.