Cyrus-SASL and IMAP and SMTP-Auth

I lost a little sleep over this, so now that it’s resolved, I’ll throw it here.  I have a Debian mail server, on which I have Email for some local user accounts (system ones, in /etc/passwd), and some virtual users in LDAP.  In order to do this I use the Courier authdaemon, which checks both those sources and lets me authenticate my IMAP and POP3 servers to them.  This works fine.  Thing is, I want to do SMTP auth as well, with Postfix.  (Note: Configuring all these things has been documented many times, look it up.)

SMTP-Auth is generally done via Cyrus-SASL (via saslauthd), which itself can look to a lot of places to determine if the user can log in.  Since I want to allow logins for SMTP to be the same for IMAP/POP, I have saslauthd try to log into my IMAP server (the rimap option, on Debian in /etc/default/saslauthd).  This worked great, until I upgraded to Debian 6.0 (“Squeeze”).

After I ran the upgrade, I was surprised to find that Thunderbird was reporting that Postfix was refusing my SMTP password.  I checked /var/log/auth.log, and found stuff like this:

Aug 21 14:11:48 clamato saslauthd[7289]: auth_rimap: unexpected response to auth request: * OK [ALERT] Filesystem notification initialization error — contact your mail administrator (check for configuration errors with the FAM/Gamin library)

ug 21 14:11:48 clamato saslauthd[7289]: do_auth         : auth failure: [user=myuser] [service=smtp] [realm=] [mech=rimap] [reason=[ALERT] Unexpected response from remote authentication server]

Now, both of the above entries are relevant, but I spent most of my time focused on the second one.  (D’oh!)  I searched around for it quite a bit, and found a couple bug reports about it from various points in the past few years.  I even tried one or two patches, but these did not work.  I tried downgrading and backporting, but these did not help.

Turns out the actually cause of this all (ie, SMTP-Auth not happening) has to do with the first line in that file, the one about FAM/GAMIN and filesystem notification.  Courier’s IMAP program likes to have this.  Apparently, it will even go so far as to tell you this when you log into the IMAP server, as I found out while finally deciding to do this via telnet.  I logged in fine, but in the login banner was the same alert message in the log…

Basically, what’s happening then is that saslauthd is logging into the IMAP server, getting the successful login response along with the alert message, and is concluding that the login was not in fact successful.  I was able to fix this just by installing the gamin package; see this page for slightly more information.

In my opinion, there is in fact a bug here, aside from my own inability to notice the other log message.   Courier logged me in successfully, even with the alert.  Saslauthd should’ve picked up on that.  Here’s the code to check this:

if (!strncmp(rbuf, TAG ” OK”, sizeof(TAG ” OK”)-1)) {
if (flags & VERBOSE) {
syslog(LOG_DEBUG, “auth_rimap: [%s] %s”, login, rbuf);
}
return strdup(“OK remote authentication successful”);
}

This is part of the auth_rimap.c file, and causes the auth_rimap function to return if the banner was correct.  However, if the banner is not exactly what it was expecting, it skips this and gives the unexpected response message.  I may put together a patch to change this, but right now I think I will go for a swim.

(On another note, I need to get a good code display plugin for this blog, so I’m not using block quotes for that.)