Enabling TLS for SAC Alerts notifications
FYI: Transport Layer Security (TLS) keeps hackers from seeing your internet traffic including the contents of the emails you send, your account passwords and the websites you read.
I aimed to keep costs low when building Steep and Cheap alerts because revenue was $0. I configured my own Postfix mail server instead of paying for services like Twilio, Mailgun and Sendgrid. My $20/month Linode server can easily host the website and handle several thousand outgoing emails per day. One downside of self hosting is having to tweak the mail server occasionally as best practices change. This happened recently when I noticed that Gmail was putting a scary broken red lock on SAC Alerts emails because the transmission was unencrypted.
The fix #
Unfortunately, I didn’t tackle this issue for a few months because I’m not an email expert. There was a risk of unintentionally breaking the alert service. After about 30 minutes of Googling, the solution turned out to be trivial.
I modified my Postfix config (/etc/postfix/main.cf) as follows:
smtp_tls_security_level = may
smtp_tls_loglevel = 1
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
smtp_tls_CAfile=/etc/ssl/certs/ca-certificates.crt
I ran postfix restart to load the new settings.
(Note: you may need to use sudo to complete these tasks)
What did I just do? #
This is the only line required to get rid of the broken red lock in Gmail. When you set it = may you enable opportunistic TLS. Before this change Postfix always used an unencrypted connection. With this change, Postfix will ask the destination server to use an encrypted connection. If the destination server does not support an encrypted connection, it will use an unencrypted connection like before.
This enables logging of TLS traffic in /var/log/mail.log. The default is zero which means no TLS traffic would be logged. Outbound emails would be delivered successfully, however, no record of them would exist in the log.
smtp_tls_session_cache_database
This is a performance optimization. It allows Postfix to reuse a previously negotiated encrypted connection. Without this setting, each mail delivery would be delayed slightly while a new connection was negotiated.
This specifies a file containing all the TLS certificates you trust. The destination server will present Postfix with a certificate proving its identity (i.e. gmail.com). This certificate will be issued by a certificate authority like LetsEncrypt, Symantec or GoDaddy. If this authority is contained in the CAfile, you will have a Trusted TLS connection. If you omit this setting, connections will be logged as Untrusted but will still use TLS.
Example TLS logging without a CAfile
Sep 29 13:32:02 teddybeard postfix/smtp[22714]: Untrusted TLS connection established to gmail-smtp-in.l.google.com[74.125.197.27]:25: TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)
Example TLS logging with a CAfile
Sep 29 13:47:50 teddybeard postfix/smtp[28095]: Trusted TLS connection established to gmail-smtp-in.l.google.com[74.125.142.27]:25: TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)
Final note #
Email services are starting to flag unencrypted deliveries. Enabling TLS for outbound email takes seconds so don’t put it off or you may scare your users.
Configuring your Postfix server to receive inbound email over an encrypted connection is slightly more complicated and requires your own TLS certificates. I may enable this on SAC Alerts at some point, but the last time I checked my Postfix inbox was probably 2016.