7

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.

Improve this question

4 Answers 4

Reset to default
17
+50

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

Improve this answer
1
  • Your answer has just crystalised the link between the line in master.cf and chroot - thank you! Although I'm sure I'd checked this countless times earlier, for whatever reason, I missed the third 'n'. I'm mystified as to how it came to suddenly change in the master.cf file, though.
    – James
    Nov 27, 2012 at 13:55
6

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");'
Improve this answer
2

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.

Improve this answer
2

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.

Improve this answer
1
  • 1
    Thanks for the reply. I think it's running - I've added the output to my question and am assuming that the output shows that it's running. I've restarted both the server and the service, but to no avail. Why might this have happened without any intervention on my part? Seems like an odd thing to happen.
    – James
    Nov 25, 2012 at 8:54

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .