Net::SMTPAuthenticationError despite valid SMTP auth credentials

[embik]

Description

To work around #1852 I have configured a local mail relay to use a valid TLS certificate and use SASL auth with local users. Despite my credentials being valid (I am able to verify this manually, see below) Portus throws a Net::SMTPAuthenticationError error. I have tried to dig into the source code to understand how smtp authentication works but I'm not familiar with Ruby enough to even find the relevant code.

Information: <dns name> and <fqdn> are not the same value later on.

Steps to reproduce

1. Configured Postfix + saslauthd on mail system, listening on port 25 and supporting StartTLS (relevant configuration is available below)
2. Created user 'portus' with password 'portus' on mail system
3. Verified credentials are valid (reference):

$ perl -MMIME::Base64 -e 'print encode_base64("\000portus\@<fqdn>\000portus")'
<Base64 encoded output>
$ openssl s_client -starttls smtp -crlf -connect <dns name>:25
<Cert verification>
250 SMTPUTF8
AUTH PLAIN <Base64 output from above>
235 2.7.0 Authentication successful

4. Configured Portus email settings the same way (see configuration below).
5. Tried to reset a user password.

• Expected behavior: Users will receive emails for password resets.
• Actual behavior: Portus webinterface goes blank and logs throw

Net::SMTPAuthenticationError (535 5.7.8 Error: authentication failed: authentication failure
):
  app/controllers/passwords_controller.rb:12:in `create'
    app/middleware/catch_json_parse_errors.rb:11:in `call'

Deployment information

Deployment method: Custom Helm Chart based on example Kubernetes resources.

Configuration:

Postfix /etc/postfix/main.cf (relevant lines):

smtpd_sasl_local_domain = $myhostname
smtpd_sasl_auth_enable = yes
broken_sasl_auth_clients = yes
smtpd_sasl_security_options = noanonymous

Postfix /etc/postfix/sasl/smtpd.conf:

pwcheck_method: saslauthd
mech_list: PLAIN LOGIN

saslauthd /etc/default/saslauthd (Debian default):

#
# 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!
#
# WARNING: DO NOT SPECIFY THE -d OPTION.
# The -d option will cause saslauthd to run in the foreground instead of as
# a daemon. This will PREVENT YOUR SYSTEM FROM BOOTING PROPERLY. If you wish
# to run saslauthd in debug mode, please run it by hand to be safe.
#
# See /usr/share/doc/sasl2-bin/README.Debian for Debian-specific information.
# See the saslauthd man page and the output of 'saslauthd -h' for general
# information about these options.
#
# Example for chroot Postfix users: "-c -m /var/spool/postfix/var/run/saslauthd"
# Example for non-chroot Postfix users: "-c -m /var/run/saslauthd"
#
# To know if your Postfix is running chroot, check /etc/postfix/master.cf.
# If it has the line "smtp inet n - y - - smtpd" or "smtp inet n - - - - smtpd"
# then your Postfix is running in a chroot.
# If it has the line "smtp inet n - n - - smtpd" then your Postfix is NOT
# running in a chroot.
OPTIONS="-c -m /var/run/saslauthd"

saslauthd /var/run/saslauthd symlinked to /var/spool/postfix/var/run/saslauthd.

Portus (relevant parts):

email:
      from: "<email from>"
      name: "<email name>"
      reply_to: "<email replyto>"
      smtp:
        enabled: "true"
        address: "<dns name>"
        port: 25
        user_name: "portus@<fqdn>"
        password: "portus"
        domain: "<fqdn>"

Information: Both portus and portus@<fqdn> don't work as email.smtp.user_name.

Portus version: 2.3.3@edd5b8201e4f9e3127053dc5b1231ae4b16a3ba7

[mssola]

I'll try to dig deeper before releasing 2.4, but I have to admit that I'm not an expert on this area 😕

[embik]

Thanks for taking a look, I'm aware this is rather weird and email configuration in general is quite a mess anyway. If I'm able to allocate some time to it I might start digging again too.

[emrahcetiner]

I use gmail for auto email. it works fine in many applications.
but the same credentials can not be sent via portus.

Sent mail to example@gmail.com (813.1ms)
Completed 401 Unauthorized in 1307ms (ActiveRecord: 3.8ms)

Net::SMTPAuthenticationError (535-5.7.8 Username and Password not accepted. Learn more at
):
app/controllers/passwords_controller.rb:14:in `create'
app/middleware/catch_json_parse_errors.rb:11:in `call'

tls should be used instead of ssl when email sending/authentication. the problem may be caused by this.

The protocol used for smtp authentication can be made configurable like this:

email:
  smtp:
    use_tls: true

[mssola]

@emrahcetiner thanks a lot for your comment!

This made me realize that we are not using all the configurable values for SMTP apparently. See what gitlab does here. Apparently they add some keys like tls which I haven't found in the ActionMailer documentation to be honest.

I'll dig deeper 👍

[mssola]

@embik the head image has been updated with #1967, so your issue should be hopefully fixed. Note that we have added more configuration options (see this). So now for you it will simply be a matter of tuning values here and there. Hope everything is fine now 😄

[embik]

Great news @mssola, thank you! I'll have to wait for 2.4 to be released but I'll try it out eventually. But it looks like these options should be enough to solve my issue :-)