As many of you know in early 2016, Gmail, in an effort to increase email security began displaying a bright red lock on emails that aren’t encrypted. While there are many articles about it, practically none of them (including Google’s!!) actually address HOW TO MEET THE REQUIREMENT to get rid of that unsightly red lock on unencrypted email transit - specifically on how to properly encrypt emails in transit from private linux email servers.
You’d think if they actually cared about email security they would include that somewhere.
The Red Lock:
I would buy an email cert if that was the answer. Or download a free email cert from somewhere if that is the answer.
This post suggests that LetsEncrypt is capable of server to server transit encryption which is what the Gmail red lock is all about. It doesn’t matter if the content itself is encrypted, only the transit.
I think LetsEncrypt is capable of this. I have my LetsEncrypt certificate working everywhere perfectly - even on imaps 993 for the server. But its not encrypting the server to server connection from Postfix. Even though its in Postfix cert and key with smtp_tls_security_level = may and smtpd_tls_security_level = may.
Is there any way to debug Postfix to make this work?
One post from that link says:
“First, there must be STARTTLS on the outgoing MX. While the LE certs do say ‘web server auth, web client auth’, no MX appears to be picky about it, and will accept the cert for SMTP regardless.”
Not sure how to get STARTTLS on outgoing messages. It seems like its working when I’ve tried to debug with telnet and openssl - 250 STARTTLS is there but it certainly isn’t working because the TLSv1_0 is missing from the top received headers on every email.
And that red lock on Gmail.
Anyone solve this?