SASL confusion in Webmin (CentOS 7, Virtualmin 6.08)

During migration work, I came to test email sending and found that SASL authentication on outbound mail appeared to be broken. I read some discussions, tried a few things and seem to have sorted it, but the web UI was confusing me a lot.

Out of the box, webmail or any device MUA got an error when attempting first to log-in, and again (after I restarted a few services) when I tried to send an email. It always failed with an authentication-related error on the client and a SASL auth-related error in maillog.

Here’s some log and config outputs from while I was having the problem:

postconf -n

postconf: warning: /etc/postfix/ undefined parameter: mua_sender_restrictions
postconf: warning: /etc/postfix/ undefined parameter: mua_client_restrictions
postconf: warning: /etc/postfix/ undefined parameter: mua_helo_restrictions
alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
allow_percent_hack = no
bounce_queue_lifetime = 4d
broken_sasl_auth_clients = yes
command_directory = /usr/sbin
config_directory = /etc/postfix
daemon_directory = /usr/libexec/postfix
data_directory = /var/lib/postfix
debug_peer_level = 2
debugger_command = PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin ddd $daemon_directory/$process_name $process_id & sleep 5
disable_vrfy_command = yes
home_mailbox = Maildir/
html_directory = no
inet_protocols = all
mailbox_command = /usr/bin/procmail-wrapper -o -a $DOMAIN -d $LOGNAME
mailbox_size_limit = 0
mailq_path = /usr/bin/mailq.postfix
manpage_directory = /usr/share/man
maximal_queue_lifetime = 4d
message_size_limit = 31457280
milter_default_action = accept
milter_protocol = 2
mydestination = $myhostname, localhost.$mydomain, localhost,
newaliases_path = /usr/bin/newaliases.postfix
non_smtpd_milters = local:/run/milter-greylist/milter-greylist.sock,inet:localhost:8891
queue_run_delay = 300s
readme_directory = /usr/share/doc/postfix-2.10.1/README_FILES
sample_directory = /usr/share/doc/postfix-2.10.1/samples
sender_bcc_maps = hash:/etc/postfix/bcc
sender_dependent_default_transport_maps = hash:/etc/postfix/dependent
sendmail_path = /usr/sbin/sendmail.postfix
setgid_group = postdrop
smtp_sasl_auth_enable = yes
smtp_tls_CAfile = /etc/ssl/certs/ca-bundle.crt
smtp_tls_ciphers = high
smtp_tls_exclude_ciphers = ${smtpd_tls_exclude_ciphers}
smtp_tls_loglevel = 2
smtp_tls_mandatory_ciphers = high
smtp_tls_mandatory_exclude_ciphers = MD5, aDSS, kECDH, kDH, SEED, IDEA, DES, ADH, RC2, RC4, RC5, PSD, SRP, 3DES, eNULL, aNULL
smtp_tls_security_level = may
smtp_use_tls = yes
smtpd_client_restrictions = reject_rhsbl_client reject_rbl_client
smtpd_data_restrictions = reject_unauth_pipelining
smtpd_helo_required = yes
smtpd_milters = local:/run/milter-greylist/milter-greylist.sock,inet:localhost:8891
smtpd_recipient_limit = 100
smtpd_recipient_restrictions = reject_unknown_reverse_client_hostname
smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated defer_unauth_destination reject_unknown_reverse_client_hostname permit_inet_interfaces
smtpd_sender_restrictions = check_sender_access pcre:/etc/postfix/sender_restrictions_bad_tlds.regexp
smtpd_tls_CAfile = /etc/postfix/
smtpd_tls_auth_only = yes
smtpd_tls_cert_file = /etc/postfix/postfix.cert.pem
smtpd_tls_ciphers = high
smtpd_tls_dh1024_param_file = /etc/postfix/dh2048.pem
smtpd_tls_key_file = /etc/postfix/postfix.key.pem
smtpd_tls_loglevel = 2
smtpd_tls_mandatory_ciphers = high
smtpd_tls_mandatory_exclude_ciphers = MD5, aDSS, kECDH, kDH, SEED, IDEA, DES, ADH, RC2, RC4, RC5, PSD, SRP, 3DES, eNULL, aNULL
smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1
smtpd_tls_received_header = yes
smtpd_tls_security_level = encrypt
smtpd_use_tls = yes
strict_rfc821_envelopes = yes
tls_random_source = dev:/dev/urandom
unknown_address_reject_code = 554
unknown_client_reject_code = 554
unknown_hostname_reject_code = 554
unknown_local_recipient_reject_code = 550
virtual_alias_maps = hash:/etc/postfix/virtual
postconf: warning: /etc/postfix/ unused parameter: tls_ssl_options=NO_COMPRESSION

saslauthd is running OK it seems;


pwcheck_method: saslauthd
mech_list: plain login
pwcheck_method: saslauthd
mech_list: plain login

service saslauthd status:

Redirecting to /bin/systemctl status saslauthd.service
● saslauthd.service - SASL authentication daemon.
   Loaded: loaded (/usr/lib/systemd/system/saslauthd.service; enabled; vendor preset: disabled)
   Active: active (running) since Wed 2020-02-05 15:29:35 GMT; 43min ago
  Process: 11963 ExecStart=/usr/sbin/saslauthd -m $SOCKETDIR -a $MECH $FLAGS (code=exited, status=0/SUCCESS)
 Main PID: 11964 (saslauthd)
   CGroup: /system.slice/saslauthd.service
           ├─11964 /usr/sbin/saslauthd -m /run/saslauthd -a pam -r
           ├─11965 /usr/sbin/saslauthd -m /run/saslauthd -a pam -r
           ├─11966 /usr/sbin/saslauthd -m /run/saslauthd -a pam -r
           ├─11967 /usr/sbin/saslauthd -m /run/saslauthd -a pam -r
           └─11968 /usr/sbin/saslauthd -m /run/saslauthd -a pam -r

Feb 05 15:29:35 systemd[1]: Starting SASL authentication daemon....
Feb 05 15:29:35 saslauthd[11964]: detach_tty      : master pid is: 11964
Feb 05 15:29:35 saslauthd[11964]: ipc_init        : listening on socket: /run/saslauthd/mux
Feb 05 15:29:35 systemd[1]: Started SASL authentication daemon..

(I restarted saslauthd earlier today after I was getting auth errors when trying to send; these now don’t occur, but mails are not sent if smtpd_sasl auth option is enabled).


# Directory in which to place saslauthd's listening socket, pid file, and so
# on.  This directory must already exist.

# Mechanism to use when checking passwords.  Run "saslauthd -v" to get a list
# of which mechanism your installation was compiled with the ablity to use.

# Additional flags to pass to saslauthd on the command line.  See saslauthd(8)
# for the list of accepted flags.

Webmin -> Servers -> Postfix -> SMTP Authentication and Encryption:

With the first ‘require SASL SMTP authentication’ enabled (equivalent to smtpd_sasl_auth_enable = yes), this error repeats in maillog and emails don’t send…

Feb  5 15:41:42 l03 milter-greylist: (unknown id): Sender IP and address <> are SPF-compliant, bypassing greylist
Feb  5 15:41:42 l03 postfix/smtps/smtpd[25709]: DDA7265D3:[], sasl_method=PLAIN,
Feb  5 15:41:42 l03 postfix/cleanup[25719]: DDA7265D3: message-id=<>
Feb  5 15:41:42 l03 opendkim[29450]: DDA7265D3: DKIM-Signature field added (s=default,
Feb  5 15:41:42 l03 postfix/qmgr[25096]: DDA7265D3: from=<>, size=1456, nrcpt=1 (queue active)
Feb  5 15:41:43 l03 postfix/smtps/smtpd[25709]: disconnect from[]
Feb  5 15:41:58 l03 postfix/smtp[28613]: fatal: specify a password table via the `smtp_sasl_password_maps' configuration parameter
Feb  5 15:41:59 l03 postfix/master[32723]: warning: process /usr/libexec/postfix/smtp pid 28613 exit status 1
Feb  5 15:41:59 l03 postfix/master[32723]: warning: /usr/libexec/postfix/smtp: bad command startup -- throttling
Feb  5 15:42:59 l03 postfix/smtp[29795]: fatal: specify a password table via the `smtp_sasl_password_maps' configuration parameter
Feb  5 15:43:00 l03 postfix/master[32723]: warning: process /usr/libexec/postfix/smtp pid 29795 exit status 1
Feb  5 15:43:00 l03 postfix/master[32723]: warning: /usr/libexec/postfix/smtp: bad command startup -- throttling

Disabling both SASL enabled options, queued emails are sent successfully, so at least that worked.

I later came to realise/remember (thanks to a linuxquestions forum thread) that smtpd_sasl_auth_enable = yes was probably the cause (as that option is for Postfix’s outbound SMTP client and requires a hashed password map), however the Webmin interface doesn’t make this obvious.

I went in and enabled both options named “Require SASL SMTP authentication?” in the SMTP auth and encryption section, because… well, why not :rofl: – and I consider myself somewhat knowledgeable about postfix configuration! Another idiot moment courtesy of confusion.

What would help is if the options weren’t identically named - and while there’s a section divider on the page, it’s not obvious what it’s separating. I know this whole section of the config UI is intended more for advanced/expert administrators, but SASL wasn’t enabled at all out of the box. And when I did enable it for the first time, I got a fairly ugly postfix bad command startup error. It seems restarting saslauthd solved that particular issue, not sure why.

On this client’s old server, which ran an old (non-Webmin) control panel with Postfix and Dovecot, SASL was enabled in a slightly different way;

smtpd_sasl_auth_enable = yes
smtpd_sasl_security_options = noanonymous
smtpd_sasl_local_domain = $myhostname
broken_sasl_auth_clients = yes
smtpd_sasl_type = dovecot
smtpd_sasl_path = private/auth

And this is why the smtpd_sasl_auth_enable option didn’t immediately flag with me as being a possible cause of the problem.

Incidentally, that old config on the old server worked from the outside and continues to work fine. It’s an old zpanel server, and they designed their user management a little differently (nothing like webmin’s unix user-based method).

I presume on the old server, dovecot is facilitating the SASL user verification as opposed to saslauthd/PAM but I’m not an expert on the intricacies of this. PAM still scares me a bit after I had a run-in with it on another of my servers (all my own fault) :wink:

Sidenote: I noticed greylist-milter was complaining about GeoIP updates. Maxmind have now made GeoLite2 database access available only to those with a (free) Maxmind acount. You have to add UserID, generate then add a free LicenceKey to the /etc/GeoIP.conf and also optionally add the GeoLite-ASN dataset, then run geoipupdate.

I subsequently realised that greylist-milter on CentOS 7 is probably obsolete anyway - if it’s not aware of geolite2. A fork of greylist-milter was published which deals with this by supporting the GeoLite2 format databases - , I may try that if feeling brave later this month. I know this is isn’t a Webmin issue per se, but thought worth mentioning as it throws errors in Postfix logs.