I've been tinkering with the encryption options in Postfix for a while. Encryption between clients and their SMTP server and between SMTP servers is necessary to protect the to, from, and subject fields, along with the rest of the header, of an email. The body of the message is also protected but it's always better to utilize PGP or S/MIME cryptography to provide end-to-end protection; encryption between clients and SMTP servers doesn't provide this.
As rolled out now, encryption between SMTP servers is opportunistic encryption and is generally not required. While doing a review of my mail log I seem to be receiving most personal mail via some encrypted circuit while much of the mail coming out of listservs, like Yahoo! Groups, is not negotiating encryption on connect. I've also noticed that some email providers actually run their incoming email through an external service, I suspect for spam control, before accepting the message into their servers. Some of these spam services don't support encryption making it difficult to protect mail in transit.
Postfix documentation is pretty decent. The project seems to document most settings but sometimes they don't actually put the entire picture together. Encryption is one of those things where a complete picture is difficult to put together just by looking at a single page of documentation.
Postfix's documentation on TLS is fairly complete. What they miss on that page, forward security, must be found else where. Until last night, I had missed that last page and now have fixed my configuration to include, what I consider, acceptable settings.
Here's what I've got:
main.cf
### TLSsmtpd_tls_security_level = maysmtpd_tls_eecdh_grade = ultratls_eecdh_strong_curve = prime256v1tls_eecdh_ultra_curve = secp384r1smtpd_tls_loglevel = 1smtpd_tls_cert_file = /etc/pki/tls/certs/mail.crtsmtpd_tls_key_file = /etc/pki/tls/private/mail.keysmtpd_tls_CAfile = /etc/pki/tls/certs/mail-bundle.crtsmtpd_tls_session_cache_timeout = 3600ssmtpd_tls_session_cache_database =btree:${queue_directory}/smtpd_scachesmtpd_tls_received_header = yessmtpd_tls_ask_ccert = yessmtpd_tls_received_header = yestls_random_source = dev:/dev/urandom#TLS Clientsmtp_tls_security_level = maysmtp_tls_eecdh_grade = ultrasmtp_tls_loglevel = 1smtp_tls_cert_file = /etc/pki/tls/certs/mail.crtsmtp_tls_key_file = /etc/pki/tls/private/mail.keysmtp_tls_CAfile = /etc/pki/tls/certs/mail-bundle.crt
master.cf
submission inet n - - - - smtpd-o smtpd_tls_security_level=encrypt-o smtpd_sasl_auth_enable=yes-o smtpd_sasl_type=dovecot-o smtpd_sasl_path=private/auth-o smtpd_sasl_security_options=noanonymous
Those familiar with setting up TLS in Apache will notice a few differences here. We haven't defined ciphers or SSL protocols. This is because this is opportunistic encryption. We're just happy if encryption happens, even using EXPORT ciphers, since the alternate is plaintext. In a more controlled setting you could define the ciphers and protocols and enforce their use. Until encryption becomes the norm on the Internet (and why shouldn't it be?) I'll have to stick with just begging for encrypted connections.
It should also be noted that client-to-SMTP server connections are forced to be encrypted in master.cf as seen in the submission portion. This was a quick and dirty way of forcing encryption on the client side while allowing opportunistic encryption on the public (port 25) side.
It should be noted that ECC keys can be used with Postfix, which forces good ciphers and protocols, but most email servers have RSA keys established so problems could arise from that. Dual keys can always be used to take advantage of both ECC and RSA.
As SSLLabs is for testing your web server's encryption settings, so is CheckTLS for checking your SMTP encryption settings. These tools are free and should be part of your regular security check of your infrastructure.