Fork me on GitHub


– Postfix's Transport Encryption under Control of the User –

PostTLS is an addition to the excellent Postfix mail server. It allows to activate mandatory TLS for all domains (e.g. to set smtp_tls_security_level = encrypt) in practice. PostTLS does this by enabling the sender of an email to delete or to send the email unencrypted if a secure connection cannot be established (e.g. because the recipients' mail server does not support transport encryption) and thus the mail was deferred to the Postfix queue.

In other words, PostTLS transfers the „send“ button of your Mail User Agent into a „send securely“ button and gives control over transport encryption to the user.

Let me explain what I mean

The State of Email Security

– and the usage of transport encryption in the wild –

Email security is important these days. However, technologies like S/MIME or OpenPGP are used very rarely. Transport Layer Security (TLS) on the other hand is supported by most email servers (about 90%).

Since there are some mail servers still out there that do not support TLS, the so-called opportunistic TLS mode is the default configuration for mail servers. Opportunistic means that the server tries to send an email through a secure connection, but if TLS is not supported by the recipients' mail server, the email is sent unencrypted. This is generally a good thing since it means that most emails are sent through encrypted connections. But for the sender of an email – especially in a corporate environment – this is not sufficient; the sender has to know if the email will be transferred encrypted to moment the „send“ button is clicked in the Mail User Agent!

The solution is mandatory TLS. And Postfix can be configured to require encryption, globally or for particular domains. The problem with mandatory TLS is that if an email cannot be delivered encrypted, it is deferred to the Postfix queue and it is up to the administrator to decide what to do now. In practice this means that the administrator must get in contact with the sender and discuss how to treat this case. This requires many administrative resources and is cumbersome for the users. That's the reason why mandatory TLS is usually used only for specific domains. Mandatory TLS for all domains is generally not recommended.

Read how PostTLS solves this problem

Transport Encryption – under Control of the User

PostTLS solves the aforementioned problem by putting the control over transport encryption into the hands of the user. You just activate mandatory TLS for all domains on your Postfix server (i.e. to set smtp_tls_security_level = encrypt). If an email is deferred to the Postfix queue because Postfix couldn't establish an encrypted connection to the recipients' mail server, PostTLS sends an email notification to the sender of the email. In this notification, the sender himself can decide how to handle this case – he can choose between two options: delete the email or send it unencrypted. The administrator does not need to intervene.

PostTLS not only lets the user control transport encryption, it also switches from „unsecure defaults“ to „secure defaults“ if mandatory TLS was used before, but only for particular domains, which is often the case in corporate environments. Let me explain: as long as mandatory TLS was used only for particular domains that were known to support TLS, the user could indeed check if the email will be encrypted; but he always had to actively check this (e.g. by looking up the information in a Customer Relationship Management system). Since most users do not really care about security, this step was often neglected. So the user didn't know if the email will be encrypted when sent. With the new defaults (e.g. mandatory TLS for all domains), the user does not even have to think about encrytion when sending an email. Since encryption is mandatory, the sender of an email can presume that the email will be delivered securely. If TLS is not supported by the recipient, the sender will be notified – and then can think about security. This is what we mean when we say PostTLS transforms the „send“ button of your Mail User Agent into a „send securely” button.

Read the Frequently Asked Questions

Frequently Asked Questions

Is PostTLS secure?

Keep in mind that PostTLS itself does not implement security features. It relies on Postfix! You could say, PostTLS implements an „insecure alternative“ to Postfix's mandatory TLS by allowing the sender to send an email unencrypted. All security relevant features, especially enforcing TLS encryption, are Postfix features, tested by thousands of users over the years. PostTLS just enhances the workflow so that the mandatory TLS feature of Postfix is usable in practice.

Is PostTLS production-ready?

PostTLS is a personal project in early stage. The author uses PostTLS on two mail servers in production with great success (about 800 mails a day). If you want to use PostTLS, please make sure that you know what you are doing. PostTLS is not a commercial product!

What do I need to run PostTLS?

PostTLS is an addition to the Postfix mail server. So you will need a running Postfix server. PostTLS does not offer a whole mail server setup; it's just an addition to an existing Postfix instance.

PostTLS is not a software for the end user. It is a software package that is meant to be used by (Linux) system administrators.

Code and Documentation

PostTLS is available under the terms of the GNU Affero General Public License version 3 (AGPLv3).
The source code is available on Github.

Get in contact

Get in Contact

Any feedback is highly appreciated! Please contact me if you have any questions and/or want to use PostTLS on your server.

Of course I'm also interested in Pull Requests to make PostTLS better! The PostTLS source code is available on Github.

Hendrik Sünkler