Inspired by the recent “E-Mail made in Germany”-initiative I had a look into how server to server encryption looks like in my postfix configuration. The latter is usually implemented using TLS and has been supported by postfix since version 2.2. Now, this was not the first time I had looked into the TLS configuration of postfix, since a while ago I had already managed to add my certificates to the postfix configuration
smtpd_tls_cert_file = /path/to/cert.pem smtpd_tls_key_file = $smtpd_tls_cert_file smtpd_tls_security_level = may
The main rationale behind this was back-then to allow mail clients like e.g. Thunderbird to use TLS/SSL in order to safely connect to the Mail Transfer Agent (MTA) — in our case postfix — such that internal mail would be at least transferred securely. Now, to my surprise I found out that this is already sufficient for other MTAs to send emails to my postfix instance securely, because they are also using the same protocol (SMTP) for the inter-MTA communication as the Thunderbird client does. The only difference is that Thunderbird does another authentication step, which then allows the user to take advantage of the relaying facilities of postfix.
So receiving emails via TLS was already working like a charm and also the corresponding configuration for allowing encrypted send was already present in my configuration
smtp_tls_security_level = may
Now you may ask: How does one notice that it is working? When receiving mails that were transferred over an TLS-encrypted channel one usually sees in the message source a remark like the following one:
Received: from mail.example.com (mail.example.com [126.96.36.199]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by example2.com (Postfix) with ESMTPS id XXXXXXXXXXX for <email@example.com>; Tue, 29 Apr 2014 19:42:40 +0200 (CEST)
Unfortunately the mail stored in the “Sent” directory of your mail client does not contain any information on that regard and one has to consult the maillog to see that sending via TLS has happened.
In principle this is already enough to obtain server to server encryption, but it may be not really satisfactory, since it does not really prevent man-in-the-middle attacks. Therefore, I started playing around a bit with the smtp_tls_policy_maps option
smtp_tls_policy_maps = hash:/etc/postfix/tls_policy smtp_tls_CApath = /path/to/certs/
where the tls_policy file contains for example
t-online.de secure ciphers=high gmx.net secure ciphers=high freenet.de secure ciphers=high web.de secure ciphers=high
This basically ensures that every mail to the listed domains is only sent encrypted with a high-quality cipher. The four given domain certificates are all (indirectly) signed by the Telekom Root Certificate, which one can e.g. download here and then place in the certs path. It should also be mentioned that after every change to the tls_policy file one should execute
and for every change on the certificates
A more intricate issue I haven’t had the time to look at yet is how to ensure that postfix only receives mail securely from the listed servers. This way one might already come pretty close to what the partners in the “E-Mail made in Germany”-initiative do. In this context I have also been asking myself whether there is a list of participating servers in this program that are using a certificate derived from the Telekom Root CA? Using this list as the tls_policy file one would at least in one direction become a defacto member of the alliance. Sadly, the website of the initiative does not seem to contain any valuable information on that regard.
For everybody else who is planning to fiddle around with the postfix TLS details I can highly recommend the documentation on the postfix webpage.
After playing around with server to server encryption I have to conclude that it is probably a nice feature, but there are still things missing:
- Is there a way to ensure that outgoing mail is encrypted? I think I read somewhere that Lavabit had such a feature.
- It is not necessarily user-friendly if you have to dig in the logs/message-source to find out whether the mail was transferred securely.
At last it is left to say that this is and will never be a substitution for end-to-end encryption but it may at least help a bit e.g. when the web traffic between two servers is routed over a foreign country with extended wire-taping capabilities.