saslauthd authentication error

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("\000username\000password");'

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.