A ‘Null Client MTA’ is an SMTP client that only provides SMTP relay services for applications running on the same host. It does not listen on a public interface. I think the etymology comes from most SMTP daemons having both a server and client component, but in this case, the server component is ‘null’ — I do not like the term because technically the server component is still there, just not on a public interface. But I digress…

This use case very common on web application (including social media and blog) servers. It is possible to configure web applications to connect to an external SMTP but it is both safer and more practical to have them connect to use an SMTP client running on the localhost.

Null MTA Client Strategies

There are three basic strategies for configuring Postfix as a Null Client MTA:

Have Postfix connect to the MX host for the mailbox domain directly

Have Postfix connect to another SMTP server (Gateway MTA) that acts as a relay

Hybrid strategy between the two

The advantage to the first: The local Postfix when properly configured can enforce DANE or PKI validation of the MX server it is connecting to, and delay delivery if there is a problem. With the second strategy, you have to trust the relay service will do that when it connects to the MX server. Unless you also administer the SMTP server you are using as a relay, you only have their word for it, if you even have that.

The advantage to the second, web application servers IP addresses often end up on spam blacklists just for being on the same subnet as a spammer, even though they did not spam themselves. It is a serious problem that inclines me to recommend the second option when your services depend upon reliable delivery of messages.

Common Configuration Options

Regardless of which strategy you choose for a Null Client MTA, there are some common configurations to make.

Make sure Reverse DNS is properly set up. Mail coming from hosts without Reverse DNS properly set up smells like spam to spam filters.

Your server should be configured to use Unbound running on the localhost in DNSSEC validation mode for name resolution. This is particularly important for the first strategy where Postfix will directly connect to destination MX servers, but it is still important in the second strategy.

Port Security

In both cases make sure Postfix is not listening on Port 25 on a public interface. With the default LibreLAMP configuration it is not, but double-verify:

That port ordinarily is blocked by default, so you should only need to specifically remove it from the public zone if for some reason the firewall has been previously configured to open it. You can check by doing a port scan from another host.

TLS Configuration

Please see the LibreLAMP Postfix TLS Configuration page for instructions on configuration of TLS. For a Null MTA client, you do not need to worry about x.509 certificate generation or Postfix MTA Server TLS Configuration. Those sections are for Postfix servers that accept connections from other hosts.

If you send through a Gateway MTA then smtp_tls_security_level can be redefined to secure or dane-only as discussed later.

DKIM Signature

Every Null Client MTA should have it’s own DKIM nickname and signing key, and it should sign the messages it sends.

This signing key should be a 2048-bit RSA key. Many tutorials recommend 1024-bit. That use to be big enough, it no longer is. Software that verifies DKIM signatures now often treat a signature from a 1024-bit key as if there is no signature at all and just ignore it, so use a 2048-bit key.

SPF Record

Make sure your SPF identifies the server is allowed to relay mail on behalf of the mailbox domain used in the From: header. Otherwise the mail may be flagged as spam.

If your Null Client MTA is directly connecting to the MX hosts for the mailbox domains the messages are sent to, then the Reverse DNS of your IP address is the hostname to add to your SPF record. If you are using another MTA as a relay, ask them what hosts should be added to your SPF record.

DMARC

I recommend against implementing DMARC.

I implemented it for several years on one of my domains as a test. The vast majority of reports it generated were false positives, as in well over 99.5% of them. One e-mail to a popular list that does not do things the way DMARC wants and even though the list sends RFC compliant e-mails, you get flooded with violation reports. Until the standard specifies a requirement for DMARC enforcing MX hosts to detect and filter out posts to mail lists from violations they report, the standard is useless.

I like the concept, but any technology that generates such a high ratio of noise reports is not usable.

Relay Through Gateway MTA

It is my recommendation that most web application servers that need to send e-mail configure Postfix to use what is sometimes called a ‘Gateway MTA’ as a relay rather than connect to a mailbox MX server directly.

The problem being solved, spam blacklists are run by companies that have no financial motive to actually do a proper job of determining who is actually a spammer and who is not. They would have more motive e-mail was not as centralized as it currently is, but that is the way capitalism works. Once an industry becomes centralized, there is no financial motive to do a proper job unless it benefits the few that own everything.

If any IP address on the same subnet you server uses is found to be sending spam, the entire subnet is added to the blacklist resulting in mail from non-spamming hosts being punished and rejected for what was not their sin.

The current system is not fair and it violates the concept of net neutrality, but at the present, there really is not a lot we can do about it. I hope to change that, but it has not yet been changed and changing it will be a fight.

Basically what you do is configure Postfix to send all outgoing e-mail through an MTA server that has agreed to act as a relay for your e-mail needs. When choosing such a relay, there are several things to take into consideration:

Are they themselves often listed on spam blacklists? If yes, do not use them.

Do they support TLS 1.2? If no, do not use them.

Do they enforce DANE for SMTP when delivering to an MX server? If no, do not use them.

Do they enforce PKIx.509 certificate validation when the mailbox domain advertises an MTA-STS policy requiring it? If no, then ask when they plan to. If they do not have an answer that satisfies you, do not use them.

Do they support connecting from Postfix? If no, then obviously you can not use them.

Does the kind of mail your web application generates violate their policy? If yes, then obviously you can not use them. Make sure to specifically ask so you have recourse if they later declare it does.

Be wary of SMTP Gateways that offer free accounts. Chances are their service is sub-par, they are often used by spammers and thus end up on black lists, they harvest tracking data from the e-mail that passes through, or all three. However just because they charge does not mean their service is quality.

The particulars of how to connect to the relay you contract with will vary by relay. Generally you will need to create a Postfix transport map (see man 5 transport). Pretend relay.example.net is the relay that has agreed to allow you to use their services. Create a file called /etc/postfix/transport containing the following:

* smtp:relay.example.net

Configure Postfix to use the transport map and create the needed hash of it:

Since we are using relay.example.net for all outgoing mail, changing smtp_tls_security_level to secure means TLS will always be used and the certificate verified.

If you know for sure the relay is committed to supporting DANE you could use dane-only instead of secure.

Hybrid Strategy

With a hybrid strategy, you still use a Gateway MTA but only when communicating with mailbox domains that reject your connection based upon your IP address.

There are some IP address white-lists you can pay to be on, and sometimes by communicating with the administrator of a mailbox domain, they will agree to manually add your outgoing MTA servers to their own manually maintained white-lists.

As some Gateway MTA services charge by the volume you send through them, using a hybrid strategy can reduce your operating costs in addition to reducing the exposure of your outgoing e-mail to a third party to the communication.

To use the hybrid strategy, configure your Null Client MTA using the first strategy but also create a transport map. Instead of putting a single wildcard * in your transport map pointing to the Gateway MTA, simply specify a line for each mailbox domain that you want relayed through the Gateway MTA.

Hybrid starttls-everywhere Strategy

If you use starttls-everywhere you need to take your Gateway MTA into consideration so that connections to it are always done either in secure or dane-only mode.

Create a file called /etc/postfix/tls_gateway_policy containing the connection mode for your Gateway MTA. For example, if the Gateway MTA is secured by DANE it might look like this:

relay.example.net dane-only protocols=TLSv1.2 ciphers=high

Then create a cron just that once an hour performs the following task: