Securing email transport - starttls, postfix, ca, certificates, fingerprint, authority, smtps

Post date: Sep 29, 2013 9:05:47 AM

I have heard often (false) claims, that if you send email, you can't be sure if it's encrypted during transport. Well, there are ways to secure that.

1) Email servers shouldn't provide non-secure option at all for end users. Only IMAPS, SMTPS (or other secure access methods like HTTPS) should be allowed at all.

2) Email server should check authenticity of the server at the other end, that's the primary point of this post.

Making sure that email is delivered over encrypted connection and only delivered to the right recipient server.

Using TLS-policy with postfix you can make it sure, that emails aren't delivered without encryption or to wrong server.

Some servers are authenticated using very strong fingerprint authentication, this means that the servers public key has to match this fingerprint. If it doesn't messages won't be delivered.

Some servers do provide valid verifiable certificate, then you should use secure transport mode. In this mode it's not enough to have encryption, it also requires that the servers cert can be verified. This option provides same security as HTTPS does (by default). Without using client certificates, nor using own CA root or more advanced stuff like that.

Then we have the last option, which is encrypt. It simply requires that email in transt has to be sent over encrypted connection. But the identity of receiving server isn't being checked at all. This is still a great option, because this still foils all passive listening attacks, but leaves transport very vulnerable to easy MitM attack.

If I would be working in high security environment, I would use fingerprint method to authenticate services. Of course this means that when ever public key is renewed also the fingerprint information has to be updated. So for most cases secure would be the recommended option.

Option recap:

fingerprint = public key fingerprint must match

secure = certificate must be valid

encrypt = connection (anonymous) encryption is required

Configuration sample:

A few sample rows for postfix TLS-policy: fingerprint

match=AD:F3:C3:68:2B:CE:8D:DA:A3:83:AC:84:F6:5B:52:E0:B4:88:CD:9B fingerprint

match=09:16:54:5E:CB:B3:7F:0B:E4:73:64:60:69:AA:4F:72:00:4F:0F:1C secure secure encrypt encrypt

Other required configuration parameters (

# TLS parameters

smtpd_tls_cert_file = your.crt

smtpd_tls_key_file = your.key

smtpd_use_tls = yes

smtpd_tls_security_level = may # could also be secure if required

smtpd_tls_ask_ccert = yes

smtpd_tls_received_header = yes # optional, if you want to add header for debug reasons

smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache

smtp_tls_cert_file = your.crt

smtp_tls_key_file = your.key

smtp_tls_security_level = may # could also be secure if required

smtp_tls_policy_maps = hash:/etc/postfix/tls_policy

smtp_tls_fingerprint_digest = sha1

smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache

Veryfiying configuration using

You can use to verify your configuration of receiving and sending secured email. The service provides you excellet report about all details why tests passed or failed.


It seems that many people misunderstand this post. No this is not about securing connections to clients. Yes, starttls can be used with clients when they send mail over smtp(s), but main point of this post is to secure email transmission between email servers.

KW: privacy, security, authority, encryption, ssl, tls, secured, secure, encrypted, delivery confirmation, strong authentication, smtp, smtps, imaps, pops, pop3s, private, server, servers, certificate, certificates, policies, fingerprint, fingerprints, mta, mail transfer agent, certificate pinning, SMX, S2SE.