SMTP Auth broken after upgrade

Virtualmin
1

I upgraded a Virtualmin managed server from Dapper to Hardy and although most things came back up with no or only minor issues, I can’t seem to get sending mail via authenticated smtp working again.

I’ve tried a number of things suggested by google searches, but nothing seems to help. I’ve been over my postfix and saslauthd configs many times and it all seems to be correct, and matches the config that I had before the upgrade. In /var/log/mail.log I get the following message when trying to send mail:

postfix/smtpd[22476]: warning: SASL authentication failure: Password verification failed

And I’ve verified that it isn’t a mail client problem by doing it by hand via a telnet session, which results in the same thing:

telnet localhost 25 Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. 220 riobu.localdomain ESMTP Postfix (Ubuntu) EHLO sdfsdf 250-riobu.localdomain 250-PIPELINING 250-SIZE 20480000 250-VRFY 250-ETRN 250-STARTTLS 250-AUTH CRAM-MD5 DIGEST-MD5 NTLM PLAIN LOGIN 250-AUTH=CRAM-MD5 DIGEST-MD5 NTLM PLAIN LOGIN 250-ENHANCEDSTATUSCODES 250-8BITMIME 250 DSN auth plain [base64 username/password was here...] 535 5.7.8 Error: authentication failed: authentication failure

Postfix is able to receive incoming mail just fine, and dovecot is authenticating POP3 and IMAP with no problems. Any suggestions for what else to look at?

2

Do you see any errors in the mail log when you authenticate? That’s in /var/log/mail.log.

Also, can you post the contents of your /etc/default/saslauthd file?

What do you see when you type this: ps auxw | grep saslauthd

And while this probably isn’t related, it looks like Ubuntu is confused about your hostname, you may want to verify that your hostname is setup correctly on the system, in /etc/hosts, and in the /etc/postfix/main.cf file.

-Eric

3

from mail.log:

Oct 4 10:48:15 1024 postfix/smtpd[7736]: connect from c-24-21-95-71.hsd1.wa.comcast.net[24.21.95.71] Oct 4 10:48:16 1024 postfix/smtpd[7736]: warning: SASL authentication failure: Password verification failed Oct 4 10:48:16 1024 postfix/smtpd[7736]: warning: c-24-21-95-71.hsd1.wa.comcast.net[24.21.95.71]: SASL PLAIN authentication failed: authentication failure Oct 4 10:48:16 1024 postfix/smtpd[7736]: warning: c-24-21-95-71.hsd1.wa.comcast.net[24.21.95.71]: SASL LOGIN authentication failed: authentication failure Oct 4 10:48:23 1024 postfix/smtpd[7736]: disconnect from c-24-21-95-71.hsd1.wa.comcast.net[24.21.95.71]

running saslauthd processes:

root 32676 0.0 0.0 7872 756 ? Ss 05:41 0:00 /usr/sbin/saslauthd -a pam -c -m /var/spool/postfux/var/run/saslauthd -r -n 5 root 32677 0.0 0.0 7872 464 ? S 05:41 0:00 /usr/sbin/saslauthd -a pam -c -m /var/spool/postfux/var/run/saslauthd -r -n 5 root 32678 0.0 0.0 7872 348 ? S 05:41 0:00 /usr/sbin/saslauthd -a pam -c -m /var/spool/postfux/var/run/saslauthd -r -n 5 root 32679 0.0 0.0 7872 348 ? S 05:41 0:00 /usr/sbin/saslauthd -a pam -c -m /var/spool/postfux/var/run/saslauthd -r -n 5 root 32680 0.0 0.0 7872 348 ? S 05:41 0:00 /usr/sbin/saslauthd -a pam -c -m /var/spool/postfux/var/run/saslauthd -r -n 5

/etc/default/saslauthd:

# # Settings for saslauthd daemon # Please read /usr/share/doc/sasl2-bin/README.Debian for details. #

Should saslauthd run automatically on startup? (default: no)

START=yes

Description of this saslauthd instance. Recommended.

(suggestion: SASL Authentication Daemon)

DESC=“SASL Authentication Daemon”

Short name of this saslauthd instance. Strongly recommended.

(suggestion: saslauthd)

NAME=“saslauthd”

Which authentication mechanisms should saslauthd use? (default: pam)

Available options in this Debian package:

getpwent – use the getpwent() library function

kerberos5 – use Kerberos 5

pam – use PAM

rimap – use a remote IMAP server

shadow – use the local shadow password file

sasldb – use the local sasldb database file

ldap – use LDAP (configuration is in /etc/saslauthd.conf)

Only one option may be used at a time. See the saslauthd man page

for more information.

Example: MECHANISMS=“pam”

MECHANISMS=“pam”

Additional options for this mechanism. (default: none)

See the saslauthd man page for information about mech-specific options.

MECH_OPTIONS=""

How many saslauthd processes should we run? (default: 5)

A value of 0 will fork a new process for each connection.

THREADS=5

Other options (default: -c -m /var/run/saslauthd)

Note: You MUST specify the -m option or saslauthd won’t run!

See /usr/share/doc/sasl2-bin/README.Debian for Debian-specific information.

See the saslauthd man page for general information about these options.

Example for postfix users: “-c -m /var/spool/postfix/var/run/saslauthd”

OPTIONS="-c -m /var/spool/postfux/var/run/saslauthd -r"
4

After lots and lots of further testing, reading miles of log files after turning on verbose logging modes, and learning stuff I never really wanted to know, I’ve been able to make a fix.

I determined that saslauthd and pam are working correctly together by using the testsaslauthd program. Then I noticed that when postfix attempted an authentication that there was no activity in the auth.log where saslauthd messages were going to, not even any messages about a failure like I could see with the test program. So apparently postfix was not able to communicate with saslauthd but instead of letting us know about the problem it just wrote “authentication failure” type messages to its log and left us in the dark.

Anyway, with that extra bit of information I was able to retarget my google searches and I tried a few shot in the dark changes to see if anything made any difference. It turns out that the smtpd.conf file is no longer being looked for in /etc/postfix/sasl, but in /usr/lib/sasl2 instead. I made a symlink in the latter location to the former and my next test mail authenticated and went through with no problems at all.

5

Wow, that’s certainly an unusual problem, I’ve never heard of that before :slight_smile:

Nice find though, and I’m glad it’s working!

-Eric

6

I have been battling with this problems for weeks. I was trying to get a my fedora configuration running on a ubuntu box. Since it was the FULL configuration, I would have thought it should have been easy, but different compiled-in path will break stuff.

This was the worst error message in the 10 years I have used postfix. But I know it’s hard (developer my self) to do good logging.

I guess I should have used the source :wink: