As noted in the previous answer, the variable smtp_sasl_password_maps
only applies to SMTP and not SMTPD. Would that the solution were as simple as pointing Postfix SMTPD to a file.
The previous answer cited what seems like an unnecessary of documentation for the problem of specifying pairs of usernames and passwords to a server. It would be nice if Postfix SMTPD had a way to fall back to a file rather than requiring the administrator to learn about a daemon with pluggable modules.
Apparently such a solution does not exist, so the problem of specifying a set of usernames and passwords to the Postfix SMTPD configuration becomes a problem of getting Postfix SMTPD to interact with a daemon called SASL. (This fact, if true, does not appear in the referenced documentation, so I'm taking some risk to claim it here)
I found the most straightforward documentation for getting Postfix SMTPD to interact with SASL here: https://wiki.debian.org/PostfixAndSASL.
I ended up being able to get Postfix SMTPD to recognize the username/password from my shell login using the first method in the above tutorial "Using saslauthd with PAM". This uses the default SASL mechanism "pam" specified in /etc/default/saslauthd
on Debian (although the tutorial tells you to create a copy of this file just for Postfix, which I did). PAM is a standard Unix authentication framework.
I remember running into some problems even with Debian's documentation, but I can't remember exactly what they were. These two commands were necessary to debug problems I encountered (substitute your own username and password):
echo MYPASSWORD | pamtester -v smptd myusername authenticate
sudo testsaslauthd -s smtp -u myusername -p MYPASSWORD
I might have had to have saslauthd
running before Postfix SMTPD would even advertise an ability to authenticate to clients.
Finally, I tested submission using msmtp
on another host. This tool didn't like the TLS keys in the default Debian Postfix configuration, so I modified main.cf
to use letsencrypt keys.
I never had to learn what a Dovecot or a Cyrus is for this solution. However, it would be preferable to have a solution which enables me to use a different password from my shell login, as now my whole system is only as secure as Postfix.