Is it not that the recipient domain has TLS enabled by default? On: no red padlock. Off: open red padlock.
On Thu, Feb 2, 2017 at 11:12 AM, Phil Pennock <mail...@spodhuis.org> wrote: > On 2017-02-02 at 08:45 -0700, Rob Nagler wrote: > > I don't understand how Google determines when to put a red lock on the > > compose. When I send to f...@bivio.com it gets a red lock, but to > > f...@bivio.biz does not. They have different MXes. The MTAs are > configured > > identically except for that mta.bivio.biz also accepts authenticated > SMTP > > on 587. Both MTAs answer EHLO with STARTTLS. Any idea how to get rid of > the > > red lock on compose in the @bivio.com case? > > I don't work for Google so don't know about them for sure, but looking > from the side: the .biz domain does not have a pre-banner delay, the > .com domain has a very lengthy pre-banner delay. > > So you hold up clients pre-banner if not known-good, on the assumption > that real clients in a store-and-forward system will wait; meanwhile > Google presumably have some kind of prober to check status for less-seen > domains and that needs to return in sufficient time to affect a > user-interface. Within any reasonable client, it can't see STARTTLS > from your server, so marks it Red. > > Disable the pre-banner delay for hosts on whitelists, and make sure that > Google's network ranges are on a sufficient whitelist to bypass the > delays, even if not to bypass other filtering? > > -Phil > > _______________________________________________ > mailop mailing list > mailop@mailop.org > https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop >
_______________________________________________ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
