Otdfbt

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.

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).

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("00username00password");'

Every time I've encountered a similar problem with saslauthd (and when everything else has been double-checked), it has been about directory/file permissions. Check each and every step of this /var/spool/postfix/var/run/saslauthd path to make sure saslauthd actually can get there.

No such file or directory when trying to connect suggests the UNIX socket it is looking for SASLAuthd on doesn't exist.

If you run ps -ef | grep saslauthd, can you see it still running?

If so, maybe see if it has its own log location.

If not it could just need a restart.