How to meet Gmail's new (2016) email tls requirement - red lock

as @pfg says, google requires reverse DNS when using IPv6 (while it is only recommended for IPv6. It also almost-requires SPF and/or DKIM when using IPv6 – you can get by without it, but then it might mark most of your mails in Spam [as it did for me]). See https://support.google.com/mail/answer/81126 for details (“Additional guidelines for IPv6” section)

About gmail and postfix and ssl : I follow instruction here : Tutorial on ejabberd, postfix, dovecot and or nginx with letsencrypt

Then :

  1. Make my ssl for belar.example.net via certbot (i use webrot method, but think any method work too)
  2. update postfix (and dovecot) to use same certificate than my webserver
  3. restart postfix

Seems OK (for me)

Received: from belar.example.net (belar.example.net. [91.xx.xx.xx])
        by mx.google.com with ESMTPS id 1si721816wrl.82.2017.02.20.00.00.46
        for <shnoulle@gmail.com>
        (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
        Mon, 20 Feb 2017 00:00:46 -0800 (PST)

But right : i didn’t find the good way for IPv6

This happened before with some ISPs in 2014 (@jsha wrote about it at ISPs Removing Their Customers' Email Encryption | Electronic Frontier Foundation). It's true that it's not always immediately clear whether it was intentional on the ISP's part; one incentive would be if the ISP wanted the ability to monitor, record, or censor outgoing e-mail, and was willing to block encrypted connections in order to do so.

You’re forgetting the most likely reason: on home networks, anything that calls out to port 25 is almost guaranteed to be a computer virus, spewing spam to the world. The ISP most likely wants to catch that before it causes problems for itself.

There is no good solution, and time machines don’t count. I personally use a VPN tunnel to work around problems like this.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.