saslauthd authentication error

My server has developed an expected problem where I am unable to connect from a mail client.

I've looked at the server logs and the only thing that looks to identify a problem are events like the following:

Nov 23 18:32:43 hig3 dovecot: imap-login: Login: user=, method=PLAIN, rip=xxxxxxxx, lip=xxxxxxx, TLS Nov 23 18:32:55 hig3 postfix/smtpd[11653]: connect from xxxxxxx.co.uk[xxxxxxx] Nov 23 18:32:55 hig3 postfix/smtpd[11653]: warning: SASL authentication failure: cannot connect to saslauthd server: No such file or directory Nov 23 18:32:55 hig3 postfix/smtpd[11653]: warning: xxxxxxx.co.uk[xxxxxxxx]: SASL LOGIN authentication failed: generic failure Nov 23 18:32:56 hig3 postfix/smtpd[11653]: lost connection after AUTH from xxxxxxx.co.uk[xxxxxxx] Nov 23 18:32:56 hig3 postfix/smtpd[11653]: disconnect from xxxxxxx.co.uk[xxxxxxx]

The problem is unusual, because just half an hour previously at my office, I was not being prompted for a correct username and password in my mail client. I haven't made any changes to the server, so I can't understand what would have happened to make this error occur.

Searches for the error messages yield various results, with 'fixes' that I'm uncertain of (obviously don't want to make it worse or fix something that isn't broken).

When I run

testsaslauthd -u xxxxx -p xxxxxx

I also get the following result:

connect() : No such file or directory

But when I run

testsaslauthd -u xxxxx -p xxxxxx -f /var/spool/postfix/var/run/saslauthd/mux -s smtp

I get:

0: OK "Success."

I found those commands on another forum and am not entirely sure what they mean, but I'm hoping they might give an indication of where the problem might lie.

When I run

ps -ef|grep saslauthd

This is the output:

root 1245 1 0 Nov24 ? 00:00:00 /usr/sbin/saslauthd -a pam -c -m /var/spool/postfix/var/run/saslauthd -r -n 5 root 1250 1245 0 Nov24 ? 00:00:00 /usr/sbin/saslauthd -a pam -c -m /var/spool/postfix/var/run/saslauthd -r -n 5 root 1252 1245 0 Nov24 ? 00:00:00 /usr/sbin/saslauthd -a pam -c -m /var/spool/postfix/var/run/saslauthd -r -n 5 root 1254 1245 0 Nov24 ? 00:00:00 /usr/sbin/saslauthd -a pam -c -m /var/spool/postfix/var/run/saslauthd -r -n 5 root 1255 1245 0 Nov24 ? 00:00:00 /usr/sbin/saslauthd -a pam -c -m /var/spool/postfix/var/run/saslauthd -r -n 5 root 5902 5885 0 08:51 pts/0 00:00:00 grep --color=auto saslauthd

If it makes any difference, I'm running Ubuntu 10.04.1, Postfix 2.7.0 and Webmin/ Virtualmin.

Solution 1:

Postfix can run in a chroot (by default in /var/spool/postfix) or not. If it is, it will try to open /var/spool/postfix/var/run/saslauthd/mux for sasl authentication. If it's not, it will try to open /var/run/saslauthd/mux

It seems that, for some reason, your postfix instance was running in a chroot, and it's not anymore. It's odd, but that's what I guess from the details of your question. If it's what's happened, you may change saslauthd configuration to use /var/run/saslauthd or run postfix in a chroot again.

To know if your Postfix is running chroot, you can check /etc/postfix/master.cf:

1. If it has the line smtp inet n - y - - smtpd or smtp inet n - - - - smtpd, then your Postfix is running in a chroot;
2. If it has the line smtp inet n - n - - smtpd then your Postfix is NOT running in a chroot.

This check comes from /etc/default/saslauthd (Ubuntu sasl configuration file).

Solution 2:

Looks like postfix always looks in the chroot'ed location for saslauthd even though its configured to NOT use the chroot environment for its services.

I found this blog post most helpful, even though it's from 2005!

http://www.jimmy.co.at/weblog/?p=52

postfix does a chroot so it can’t communicate with saslauthd. This is the tricky part:

rm -r /var/run/saslauthd/ 
mkdir -p /var/spool/postfix/var/run/saslauthd 
ln -s /var/spool/postfix/var/run/saslauthd /var/run 
chgrp sasl /var/spool/postfix/var/run/saslauthd 
adduser postfix sasl

You can run saslauthd in debug mode using:

saslauthd -c -d -a pam -m /var/run/saslauthd

From your client, do this:

openssl s_client -CApath /etc/ssl/certs/ -starttls smtp -connect mail.mydomain.com:587

When prompted type this:

HELO mynotebook.com
LOGIN PLAIN <base64code>

where the base64code bit comes from this:

perl -MMIME::Base64 -e 'print encode_base64("\000username\000password");'