我的服务器开发了一个预期的问题，我无法从邮件客户端连接。
我查看了服务器日志，唯一看起来确定问题的事情是像下面这样的事件：
11月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]：从xxxxxxx .co.uk [xxxxxxx] 11月23日18:32:55 hig3 postfix / smtpd [11653]：警告：SASL身份validation失败：无法连接到saslauthd服务器：无此文件或目录11月23日18:32:55 hig3 postfix / smtpd [11653]：警告：xxxxxxx.co.uk [xxxxxxxx]：SASL LOGIN身份validation失败：通用失败11月23日18:32:56 hig3 postfix / smtpd [11653]：来自xxxxxxx.co.uk的AUTH之后丢失连接[xxxxxxx] 11月23日18:32:56 hig3后缀/ smtpd [11653]：从xxxxxxx.co.uk断开[xxxxxxx]
这个问题是不寻常的，因为在我的办公室只有半个小时，我的邮件客户端没有被提示input正确的用户名和密码。 我没有对服务器做任何改变，所以我不明白会发生什么事情发生这个错误。
search错误消息会产生各种结果，“修复”我不确定（显然不想让事情变得更糟或者修复没有被破坏的东西）。
当我跑步
testsaslauthd -u xxxxx -p xxxxxx
我也得到以下结果：
connect（）：没有这样的文件或目录
但是当我跑步
testsaslauthd -u xxxxx -p xxxxxx -f / var / spool / postfix / var / run / saslauthd / mux -s smtp
我得到：
0：确定“成功”。
我在另一个论坛上发现了这些命令，我不完全确定它们是什么意思，但是我希望能够指出问题可能出在哪里。
当我跑步
ps -ef | grep saslauthd
这是输出：
根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
如果它有什么区别，我正在运行Ubuntu 10.04.1，Postfix 2.7.0和Webmin / Virtualmin。
Postfix可以运行在chroot中（默认情况下在/var/spool/postfix ）或者不运行。 如果是，它将尝试打开/var/spool/postfix/var/run/saslauthd/mux进行sasl身份validation。 如果不是，它会尝试打开/var/run/saslauthd/mux
看起来，出于某种原因，你的后缀实例是在一个chroot中运行的，现在已经不复存在了。 这很奇怪，但这是我从你的问题的细节猜测。 如果发生了什么情况，可以将saslauthdconfiguration更改为使用/var/run/saslauthd或者在chroot中再次运行postfix。
要知道你的Postfix是否正在运行chroot，你可以检查/etc/postfix/master.cf ：如果它有smtp inet n - y - - smtpd或者smtp inet n - - - - smtpd ，那么你的Postfix正在运行一个chroot。 如果它有smtp inet n - n - - smtpd那么你的Postfix不在chroot中运行。 这个检查来自/ etc / default / saslauthd（Ubuntu saslconfiguration文件）。
看起来像postfix总是在chroot的位置为saslauthd即使它被configuration为不使用chroot环境的服务。
我发现这个博客文章最有帮助，即使是从2005年开始！
http://www.jimmy.co.at/weblog/?p=52
postfix做一个chroot，所以它不能和saslauthd通信。 这是一个棘手的部分：
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
您可以使用以下方式在debugging模式下运行saslauthd ：
saslauthd -c -d -a pam -m /var/run/saslauthd
从你的客户，这样做：
openssl s_client -CApath /etc/ssl/certs/ -starttls smtp -connect mail.mydomain.com:587
当提示时input：
HELO mynotebook.com LOGIN PLAIN <base64code>
base64code位来自这里：
perl -MMIME::Base64 -e 'print encode_base64("\000username\000password");'
每当我遇到与saslauthd类似的问题时（以及其他所有问题都经过了双重检查），它一直是关于目录/文件权限的。 检查这个/var/spool/postfix/var/run/saslauthdpath的每一步，以确保saslauthd实际上可以到达那里。
尝试连接时没有这样的文件或目录表明它正在寻找SASLAuthd的UNIX套接字不存在。
如果你运行ps -ef | grep saslauthd ps -ef | grep saslauthd ，你能看到它仍在运行吗？
如果是这样，也许看看它是否有自己的日志位置。
如果不是，它可能只需要重新启动。