How to configure postfix in 2024.

This howto is aimed at someone installing Postfix at his or her own VPS, in order to have a self-hosted mail server for one or several people (not a company), and enjoy the benefits that self-hosted mail provides.

The howto tries to follow two principles:

1. Make things as simple and minimalist as possible, but allow further scaling when required.
2. Provide as many test cases as possible.

With an exception of hosting a somewhat dated submission STARTTLS service on port 587 (which can be omitted), and the log watcher (which is still immensely helpful), none of the steps in this HOWTO can be avoided.

Rewriting addresses in case of mail forwarding are done using an improvised method, which might be less beneficial than postsrsd. The author is interested in feedback on this subject: if some reader includes postsrsd and finds that its rewriting method is better in some respect, the author would be interested in comments.

Setting up your own mail is not that simple, and this is unavoidable, because E-Mail is a social system. Yes, it is a social system, because it can be used by people talking to people. And as social systems evolve, they start to exhibit properties of social systems observed already by Plato and Aristotle.

E-Mail used to be a very democratic system, and although gradually over time it became more oligarchic, to combat some ochlocratic tendencies, such as SPAM. Even so, the presence of multiple oligarchs which are competing among themselves, so far has left us able to flow between the raindrops.

Matching oligarchs requirements requires a bit of work, but so far most of this work is possible to perform cheaply, or even with no money spent at all.

1. Domain name. :: I don't know a way to get one for free, but … sometimes you can get one from your ISP.
2. DNS provider. :: Well, you can host one yourself, but there are free providers over there, with an excellent interface.
3. An unassuming and unpretending free email provider which can receive mail. :: Same thing. This is not strictly requires, but nice to have. Let's call him badmail.test
4. A hosting provider with a VM or at least with a mutable container. :: You can host at home, of course, but a "Cloud VM" is better.
5. A real email provider that you are using when your self-hosted mail is down. Say, oligarch.com
6. A way to pay for all of those. :: Paypal? Bitcoin? Card? Whatever.

postqueue -j | jq -r '.queue_id' | postsuper -d -

or

postqueue -d ALL

you can also stop all the services mentioned in this howto by running

/etc/rc.d/rc.postfix stop ; /etc/rc.d/rc.opendkim stop

1. postfix
2. opendkim
3. msmtp
4. acme.sh
5. nail

Occasionally mentioned are:

1. postsrsd
2. opensmtpd
3. ssh
4. tmux
5. tcpdump
6. tshark/wireshark

You may have to search for what some of those programs do.

I did most of the debugging having a tmux session on the remote server, with 3 windows open:

1. Console for sending mail with nail or msmtp
2. tail -f /var/log/maillog
3. tcpdump -vvv -n -i any 'port 25'

I know what you are thinking about "tcpdump? wtf?", but yes, tcpdump. SMTP is a plain-text protocol, so you can see where bad things happen.

You have to turn tls off though.

TLS is the server-side encryption standard we use today. It essentially consists of two parts: private key and public key. Public key is used by everyone to encrypt messages sent to you, and private key is used by you to decrypt those messages.

Of course, TLS does not just work in one direction, it works in both directions, but to initiate a connection it is enough to send a private message to recipient once.

I suggest getting a tls certificate using acme.sh with a DNS challenge. You can use HTTP challenge too, but it requires maintaining an HTTP server, and is generally less fun to setup as it is more stateful.

Use acme.sh

I will not write the full script here, but you need to run the script twice, to apply for a cert and to issue a cert.

1. acme.sh --home /root/.acme.sh --server letsencrypt --issue --days 60 --dns -d domain.test -d subdomain1.domain.test -d subdomain2.domain.test --yes-I-know-dns-manual-mode-enough-go-ahead-please
2. for i in "${domainArray[@]}" ; do update_ddns.sh ; done
3. acme.sh --home /root/.acme.sh --server letsencrypt --issue --days 60 --renew --dns -d domain.test -d subdomain1.domain.test -d subdomain2.domain.test --yes-I-know-dns-manual-mode-enough-go-ahead-please

This is finicky funky stuff, but you should get it eventually.

It will produce two files: tls-certificate-acme.sh.fullchain.crt, the public key, and tls-certificate-acme.sh.key, the private key.

1. chmod +x /etc/rc.d/rc.postfix
2. /etc/rc.d/rc.postfix start

But it is better to first enable both Internets we are living in now in postfix's main.cf

+#inet_protocols = ipv4
+inet_protocols = all

Let us check.

Good.

So, there are two methods:

1. aliases
2. bcc

Aliases is the file /etc/aliases, which allows you to show where to duplicate a message if you are sending it to a local user. You can check its syntax by man aliases, and do not forget to run postalias after editing it.

However, for a start, I recommend editing always_bcc in main.cf. Set it to your badmail address.

#main.cf
always_bcc = user@badmail.test

In addition, I suggest adding the following setting in order to receive error reports from postfix itself when things go wrong:

notify_classes = bounce, delay, policy, protocol, resource, software

Errors are not subject to always_bcc, so you will need to edit /etc/aliases anyway (that is why introduced it first) and add user@badmail.test after postmaster. postmaster is a magical domain which is there for receiving mail errors.

cd /etc/postfix ; postalias aliases

Again, it is better to only add optional encryption, since receiving unencrypted mail can be useful.

We will use those keys that you should have prepared 2.2

# main.cf
smtpd_tls_security_level = may
smtpd_tls_cert_file = /etc/ssl/tls-certificate-acme.sh.fullchain.crt
smtpd_tls_key_file = /etc/ssl/private/tls-certificate-acme.sh.key

Test from your laptop by:

echo "Test $(( I = I + 1 ))" | \
  nail -v -s 'test-public-port-25' \
       -S mta='smtp://mailer.domain.test' \
       -S smtp-use-starttls\
       -S smtp-auth=none\
       -S v15-compat=yes\
       user@mailer.domain.test

This should succeed, because mail should be accepted to a local destination.

Also test on your laptop:

echo "Test $(( I = I + 1 ))" | \
  nail -v -s 'test-public-port-25' \
       -S mta='smtp://mailer.domain.test' \
       -S smtp-use-starttls \
       -S smtp-auth=none \
       -S v15-compat=yes \
       user@oligarch.com

This should fail, because relaying to oligarch.com over port 25 should be refused even the port supports encryption.

Yes. So far we have done everything that can be done without exposing ourselves to the world as people with an identity. We used IP addresses, nonexistent domain names, and sender rewriting. Now we are planning to interact with the external world.

Some of it can be done with self-generated keys and localhosted domains, but really the next steps are about interacting with the rest of the world. Let us assume that your domain is domain.test.

1. Generate a DKIM key buy running /etc/rc.d/rc.opendkim (and add starting it to rc.local)
2. You need at least four A and (AAAA) records, for domain.test and for mailer.domain.test, with IP addresses.
3. You will need least one MX record with mailer.domain.test.
4. You will need an SPF (TXT) record like this: v=spf1 mx -all on domain.test, and maybe "v=spf1 a -all" on mailer.domain.test.
5. You will need a DMARC record _dmarc.domain.test like this "v=DMARC1;p=none;pct=100;rua=mailto:postmaster@mailer.domain.test , this is for the place where spam violations will be sent. (Aren't those the errors which we have done so much to be able to receive?)
6. Set up a DKIM record default._domainkey.domain.test with the value that opendkim has generated for your in /etc/opendkim/keys/. These are NOT the TLS keys.

Well… technically you can, and this would work, but would not be terribly useful, since the mail server would have the SPF trust level anyway.

So, surprisingly, I refer you to the point to really read about DKIM and OpenDKIM.

Add the following to main.cf

submission inet n       -       n       -       -       smtpd
  -o syslog_name=postfix/submission
  -o smtpd_tls_security_level=encrypt
  -o smtpd_sasl_auth_enable=yes
  -o smtpd_tls_auth_only=yes
  -o smtpd_reject_unlisted_recipient=no
#  -o smtpd_client_restrictions=$mua_client_restrictions
#  -o smtpd_helo_restrictions=$mua_helo_restrictions
#  -o smtpd_sender_restrictions=$mua_sender_restrictions
  -o smtpd_recipient_restrictions=
  -o smtpd_relay_restrictions=permit_sasl_authenticated,reject
  -o milter_macro_daemon_name=ORIGINATING
smtps     inet  n       -       n       -       -       smtpd
  -o syslog_name=postfix/smtps
  -o smtpd_tls_wrappermode=yes
  -o smtpd_sasl_auth_enable=yes
  -o smtpd_reject_unlisted_recipient=no
#  -o smtpd_client_restrictions=$mua_client_restrictions
#  -o smtpd_helo_restrictions=$mua_helo_restrictions
#  -o smtpd_sender_restrictions=$mua_sender_restrictions
  -o smtpd_recipient_restrictions=
  -o smtpd_relay_restrictions=permit_sasl_authenticated,reject
  -o milter_macro_daemon_name=ORIGINATING

Sometimes your system might have submissions instead of smtps. Mapping of "services" to ports is done in /etc/services.

The important bit here is smtpd_relay_restrictions=permit_sasl_authenticated.

It will prohibit sending mail with this port, unless one is authenticated using "sasl". SASL is essentially "login/password smtp authentication". It is not the only model which makes sense even for a home setup. For example, one might imagine a TLS client-certificate authentication.

You need to run the following tests:

So, in OpenSMTPd this is super easy, just use the listen directive with an auth keyword, and users will be authenticated with their system login/password pair.

But Postfix is enterprise-level software, so it expected something called SASL-daemon.

Slackware has cyrus-sasl and rc.saslauthd.

I used the following guide, https://wiki.archlinux.org/title/Postfix_with_SASL , but the pam_other issue that they are mentioning does not exist on Slackware, so things are a bit easier. The official documentation of Postfix surprisingly makes sense in this question too (http://www.postfix.org/SASL_README.html).

1. enable rc.saslauthd :: chmod +x /etc/rc.d/rc.saslauthd
2. Edit /etc/sasl2/smtpd.conf
3. /etc/rc.d/rc.saslauthd restart
4. Nothing required on the postfix side, because permit_sasl_authenticated,reject has already been introduced, but you can restart postfix for clarity. /etc/rc.d/rc.postfix restart

# /etc/sasl2/smtpd.conf
pwcheck_method: saslauthd
mech_list: PLAIN LOGIN
log_level: 7

So, SASL is a generic authentication daemon (which includes a plain password method). PAM is a system login method. Postfix asks SASL, and gives it a login and a password, and SASL asks PAM, and forwards the login and password to it. PAM can delegate password checking again somewhere, say, to SASL, which will in turn ask PAM, and so on and so on, and we will have a nice sweet authentication loop which will hang your system. But usually PAM asks the passwd (UNIX) database instead.

Important note: your password must be as simple as possible, in order to not be mangled by byte-encoding conversions, and other annoying system limitations. It does not, however, mean that your password should be weak, you should make it strong by the most obvious method – make it looooong. At least 64 symbols, desirably all from just Latin alphabet, possibly with digits.

In fact, you can make SASL check the shadow database by itself, without PAM, or it can even query its own database sasldb. You can also make Postfix query Dovecot, not using cyrus-sasl at all.

Well, let us check:

By this time you should be able to receive mail to "user@mailer.domain.test", but receiving mail to a mailer user is not terribly useful. Sometimes you may want to make your systems exchange logs or certificates, but even in this case, doing those exchanges by mail is harder than over, say, SSH. The only benefit really is being able to accept anonymous messages from machines which do not have proper ssh, or have outdated TLS certificates, or such.

Now when you receive mail, you have a painful choice to make:

1. Do you want to maintain your own JMAP/IMAP server?
2. Do you want to just forward everything to an oligarch and call it a day?

In theory the option 1 is better, because it actually allows you to control your information flow as you want it. However, the option 2 is not without its merits: (1) many people do not have a good information flow system, (2) those who do may already have an established workflow with an oligarch's service, (3) in some cases an oligarch's service ends up less costly.

My choice is going with an oligarch, which creates one more choice:

1. Make the oligarch's service collect your mail.
2. Make your server send the mail to the oligarch.

Option 1 is usually better, because it is more likely to catch errors – if you configure oligarch.com to collect your mail by POP3, OLigomail will complain if your server ends up being broken. However, this requires maintaining your own POP server, requires more "state" to be configured on it, and not all oligarch's services support mail collection.

So let us do option 2.

Lol, now. Sometimes you have addresses like this:

1. MAIL FROM :: cmake+verp-3d0a58993745ed18eea3ea75a1641ead@discourse.cmake.org
2. From: noreply@cmake.org

DMARC for cmake.org is set up so as to prevent forwarding, so if you forward message with these addresses, and a DKIM sign, to OLigomail, it will be rejected.

What shall we do?

We will rewrite the MAIL FROM address just like we did with mail to badmail.

Add another transport:

#master.cf
msmtp_for_olig unix -  n    n    -    50    pipe
    flags=R user=nobody argv=/etc/bin/postfix-to-msmtp-wrapper_olig.bash --sender=${sender} --user=${user} --extension=${extension} --recipient=${recipient}

# /etc/bin/postfix-to-msmtp-wrapper_olig.bash
l_sender="${sender/@/==}"_rewrite@my-domain.test
MX=$(dig MX oligomail.com | grep -A1 'ANSWER SECTION' | tail -n 1 | awk '{print $6;}')
MX="${MX%.}"
exec msmtp --host="$MX" --port=25 --tls=on --from="$l_sender" "$recipient" 2>&1

In my case it worked for 90% of the cases, with an exception of SPF-enabled domains without DKIM. I will leave dealing with such domains as a simple homework to the reader.

https://serverfault.com/questions/24121/understanding-a-postfix-log-file-entry

For each message there will be two entries: delay and delays=a/b/c/d, they mean time spent by Postfix on processing the message.

1. a :: receiving SMTP session
2. b :: in queue
3. c :: connection setup
4. d :: message transmission

https://wiki.archlinux.org/title/Postfix#Secure_SMTP_(receiving):~:text=Hide%20the%20sender%27s%20IP%20and%20user%20agent%20in%20the%20Received%20header%5Bedit%20source%5D