Postfix email server remote login

Note: I no longer run my own mail server because delivery is difficult.

After a few days I found my new mail server so useful I wanted our laptops and smart phones to use it as well. Remote clients like smart phones need to log in using a Simple Authentication and Security Layer (SASL) module on the server. As always the specific instructions will depend on your Linux distribution but the following works for Debian 10. It stores passwords in a Berkeley DB database. Very simple and reliable.

Much of the complexity of a full-blown email solution is avoided by this setup: no database to store user email, no mailboxes, no web mail interface, just a bare bones server sending emails. Then how do I receive emails? By using email forwarding: NameCheap, the domain registrar for my websites, forwards all email sent to craig@seagrape.us to my home email address. Many domain registrars, including NameCheap, provide this service for free.

Setup

0. Install Postfix MTA for local sending using these instructions

1. Create an SPF (Sender Policy Framework) record

Creating an SPF record is optional but recommended because it keeps your outgoing mail from ending up in a spam folder somewhere. If your mail server (hal.example.com for example) will be sending emails on behalf of your other domain (foo.net for example), the recipient can ask foo.net: does hal.example.com have permission to send mail for you? If not it’s treated as spam.

Your domain registrar has online tools for creating and modifying your site’s DNS records. Create a TXT record for foo.net:

Type:   TXT
Host:   @
Value:  v=spf1 a:hal.example.us ~all

2. Create an SSL certificate for Hal.

Encrypt the SMTP server connections (to prevent eavesdropping) using a free SSL certificate from LetsEncrypt.

apt install certbot
certbot certonly --standalone -d hal.example.com

The output will be something like the following. Write down the path it gives because we’ll use it to update the Postfix configuration file.

Congratulations! Your certificate and chain have been saved at:
/etc/letsencrypt/live/hal.example.com/fullchain.pem
Your key file has been saved at:
/etc/letsencrypt/live/hal.example.com/privkey.pem

3. Install SASL (Simple Authentication and Security Layer) packages

The SASL module handles remote logins.

apt install libsasl2-modules sasl2-bin

4. Configure the SASL module

Create a file /etc/postfix/sasl/smtpd.conf and add the following lines:

pwcheck_method: auxprop
auxprop_plugin: sasldb
mech_list: plain login

These settings are explained at the Postfix SASL page.

5. Add a user to the database

saslpasswd2 -c -u domain user

If you want to add david@example.com:

saslpasswd2 -c -u example.com david

You’ll be prompted for a password.

List the users in the database:

sasldblistusers2

6. Configure Postfix chroot environment

Postfix needs /etc/sasldb2 in its chroot environment. Edit /usr/lib/postfix/configure-instance.sh and add etc/sasldb2 to the variable FILES:

    FILES="etc/localtime etc/services etc/resolv.conf etc/hosts \
        etc/host.conf etc/nsswitch.conf etc/nss_mdns.config etc/sasldb2"

7. Edit Postfix configuration

Edit /etc/posfix/main.cf using the postconf utility:

postconf -e 'smtpd_sasl_local_domain = $myhostname'
postconf -e 'smtpd_sasl_auth_enable = yes'
postconf -e 'smtpd_sasl_security_options = noanonymous'
postconf -e 'smtpd_tls_cert_file=/etc/letsencrypt/live/hal.example.com/fullchain.pem'
postconf -e 'smtpd_tls_key_file=/etc/letsencrypt/live/hal.example.com/privkey.pem'
postconf -e 'smtpd_use_tls=yes'

Restart postfix:

systemctl daemon-reload

8. Test the SMTP login

I use the Swaks utility to test SMTP authentication.

a. Check for open email relay (open relays are evil):

swaks --to noname@erewhon.com --server hal.example.com

Should receive

Relay access denied

b. Check for authenticated relay: Using the login credentials from step 5:

swaks --to <to-email-address> --from david@example.com
--auth-user david@example.com --server hal.example.com 'testing'

And your email should be delivered. That’s it.

Why not DKIM?

Why didn’t we configure the server to use DKIM authentication? We use SPF because it’s simple to configure: create a single DNS record once and you’re done.

DKIM (DomainKeys Identified Mail) is quite a bit more complicated. You generate a public/private encryption key pair and DKIM inserts a digital signature based on the private key into the header of each outgoing email. Your server publishes the public key in a DNS record so the destination server can use it to verify the digital signature. DKIM recommends you generate new keys every few months which means you have to modify your DNS records several times a year…forever. Not exactly fire-and-forget which is the optimal server configuration.

So I skipped DKIM and used an email validator to ensure outgoing emails don’t look spammy.