1

I am upgrading a postfix email server from Debian Bullseye to Trixie. The server is using saslauthd which is using the /etc/shadow file for authentication.

The issue: a Ruby on Rails application that used to authenticate correctly using the ActionMailer library and plain authentication, fails to authenticate with the following log output in /var/log/mail.log:

2025-09-15T18:21:40.114455+00:00 ip-10-30-73-92 postfix/master[29793]: daemon started -- version 3.10.4, configuration /etc/postfix         
2025-09-15T18:21:50.481732+00:00 ip-10-30-73-92 postfix/submission/smtpd[29800]: connect from ip-10-30-69-201.ec2.internal[10.30.69.201]    
2025-09-15T18:21:50.497428+00:00 ip-10-30-73-92 postfix/submission/smtpd[29800]: warning: SASL authentication failure: Password verification
 failed                                                                                                                                     
2025-09-15T18:21:50.497618+00:00 ip-10-30-73-92 postfix/submission/smtpd[29800]: warning: ip-10-30-69-201.ec2.internal[10.30.69.201]: SASL PLAIN authentication failed: authentication failure, sasl_username=noreply                                                                   
2025-09-15T18:21:50.498644+00:00 ip-10-30-73-92 postfix/submission/smtpd[29800]: NOQUEUE: lost connection after AUTH from ip-10-30-69-201.ec
2.internal[10.30.69.201]                                                                                                                    
2025-09-15T18:21:50.498745+00:00 ip-10-30-73-92 postfix/submission/smtpd[29800]: disconnect from ip-10-30-69-201.ec2.internal[10.30.69.201] 
ehlo=2 starttls=1 auth=0/1 commands=3/4

Things I have done to aid the transition and eliminate other potential issues:

1.) I have performed what you see in the following answers in regards to ensuring saslauthd has a correct PID location as well as an updated /var/run location within the postfix chroot: Saslauthd service not starting after upgrade to Ubuntu 24.04

2.) Run sudo testsaslauthd -f /var/spool/postfix/var/run/saslauthd/mux -u noreply -p '[PASSWORD]' and received 0: OK "Success." Changing this to a slightly different password correctly results in failure.

3.) Removed @ symbols from the password (where there were some), whereas it seems like @ in usernames can cause problems in saslauthd requiring a more elaborate configuration I wished to avoid: https://forum.virtualmin.com/t/sasl-authentication-fails-for-usernames-with-an/116527 This did not make a difference in postfix and testsaslauthd succeeded with the new passwords.

Is there anything I'm missing? My attempts with mailx and openssl s_connect have failed to authenticate as well, when pasting in the output of $( echo -n "noreply:[PASSWORD]" | base64) to the AUTH PLAIN prompt. Does the username/password need to be null-terminated instead?

Thanks in advance.

EDIT:

I've dug further and now saslauthd and postfix are talking. The issue seems to be a successful auth using testsaslauthd is using service smtpd whereas the unsuccessful authentication from the application somehow is using service stmp.

Good:

saslauthd[14762] :auth success: [user=noreply] [service=smtpd] [realm=] [mech=pam]
saslauthd[14762] :response: OK

BAD

saslauthd[14763] :[login=noreply] [service=smtp] [realm=]: not found, update pending
saslauthd[14763] :attempting to release lock on slot: 718
saslauthd[14763] :auth failure: [user=noreply] [service=smtp] [realm=] [mech=pam] [reason=PAM auth error]

What do I need to check to make this right?

Improve this question
4
  • Can you try after increasing log level of postfix? This should work adding/editing debug_peer_list = 10.30.69.201 and debug_peer_level = 3 in main.cf. Commented Sep 16 at 8:45
  • Thank you for the tip. Changing this made logs show the password coming in base64-encoded, and when decoded the password did NOT quite match echo -n "noreply:[PASSWORD]" | base 64 but when decoded was simply noreply[PASSWORD] on the CLI using base64 --decode. However, that may be a side effect of them being null-terminated and those null terminated characters not making it to stdout. No smoking gun as far as I can tell. Commented Sep 16 at 15:52
  • Running saslauthd in the foreground with saslauthd -a pam -d -r -c -m /var/spool/postfix/var/run/saslauthd, I can not get authentication logging to show up around the time postfix reports its failure. I can with testsaslauthd. I am beginning to suspect the postfix chroot can't talk to saslauthd in its current configuration. Commented Sep 16 at 16:20
  • I've dug further and the request that's failing is using service smtp whereas requests that succeed are using service smtpd, repeated above. What do I need to check/change here? Commented Sep 16 at 17:21

1 Answer 1

Reset to default
0

To other readers: If you've come this far with this configuration, I'm afraid I can't provide anything definitive as to what was going on with the pam configuration. Something approximating postfix operating under the smtpd service as opposed to the smtp service needed to happen. PAM seemed fine to play around with the smtpd service, but perhaps needed another file smtp.conf to succeed with the smtp service. Creating such a file didn't work for me. What worked for me was switching saslauthd auth mechanism in /etc/default/saslauthd from pam to shadow, and ensuring my users were configured with the correct passwords.

Improve this answer
1
  • Postfix has both smtp and smtpd services -- the latter is the inbound service, and is the only one that needs to authenticate your users. Commented Sep 20 at 3:11

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.