Google mail admin contact needed (STARTTLS capabilities issue)

Mailman List Mirror (Read Only)
1

There appears to be a widespread issue with Google inbound MX's
yesterday/today and I am unable to reach sufficient levels of support
from Google tickets or forums.

The problems seems to be many, if not all inbound Google MX records
for Gmail.com and Google Apps hosted domains are no longer reliably
advertising TLS as being supported over port 25 via STARTTLS.
It also appears TLS on connect over port 465 is also spotty at best,
with some servers responding, and some not. Previously 465 was
recommended by Google for mail clients to use, but seems to be
experience issues the last day or so intermittently.

This has been preventing opportunistic TLS from working over the last
couple days for my personal Google apps domain, and verified with
several other Google apps hosted domains.
However, Postini inbound MX'es still show STARTTLS in the capabilities
list after EHLO, so this seems to be only Google MX'es, not impacting
those who use Postini.

For example, below shows the same MX at Google responding with and
without TLS. I attempted about a dozen times over a few minutes to the
same MX until I got STARTTLS listed in the capabilities list, but the
next attempt to the same MX would no longer show STARTTLS

Any assistance on or off list would be appreciated.

(08:17 PM Fri Dec 03)-(~)
$ telnet alt1.gmail-smtp-in.l.google.com 25
Trying 209.85.229.27...
Connected to alt1.gmail-smtp-in.l.google.com.
Escape character is '^]'.
220 mx.google.com ESMTP y73si4442013weq.155
ehlo domain.com
250-mx.google.com at your service, [64.124.180.7]
250-SIZE 35651584
250-8BITMIME
250 ENHANCEDSTATUSCODES

(08:20 PM Fri Dec 03)-(~)
$ telnet alt1.gmail-smtp-in.l.google.com 25
Trying 209.85.229.27...
Connected to alt1.gmail-smtp-in.l.google.com.
Escape character is '^]'.
220 mx.google.com ESMTP j3si4484656wbc.99
ehlo domain.com
250-mx.google.com at your service, [64.124.180.7]
250-SIZE 35651584
250-8BITMIME
250-STARTTLS
250 ENHANCEDSTATUSCODES

(08:22 PM Fri Dec 03)-(~)
# telnet alt4.gmail-smtp-in.l.google.com 25
Trying 74.125.67.27...
Connected to alt4.gmail-smtp-in.l.google.com.
Escape character is '^]'.
220 mx.google.com ESMTP g16si6002830ibb.2
ehlo domain.com
250-mx.google.com at your service, [64.124.180.7]
250-SIZE 35651584
250-8BITMIME
250-STARTTLS
250-ENHANCEDSTATUSCODES
250 PIPELINING

(08:26 PM Fri Dec 03)-(~)
# telnet alt4.gmail-smtp-in.l.google.com 25
Trying 74.125.67.27...
Connected to alt4.gmail-smtp-in.l.google.com.
Escape character is '^]'.
220 mx.google.com ESMTP e7si5973534ibb.84
ehlo domain.com
250-mx.google.com at your service, [64.124.180.7]
250-SIZE 35651584
250-8BITMIME
250-ENHANCEDSTATUSCODES
250 PIPELINING

(08:28 PM Fri Dec 03)-(~)
$ telnet ASPMX.L.GOOGLE.COM 25
Trying 74.125.91.27...
Connected to ASPMX.L.GOOGLE.COM.
Escape character is '^]'.
220 mx.google.com ESMTP n7si5304773qcu.37
ehlo domain.com
250-mx.google.com at your service, [64.124.180.7]
250-SIZE 35651584
250-8BITMIME
250 ENHANCEDSTATUSCODES
STARTTLS
502 5.5.1 Unrecognized command. n7si5304773qcu.37

2

Equally troubling is the similarly random nature of PIPELINING, which doesn't
even match the STARTTLS appearing or not. Definitely bad juju.

3

Yah, I've been trying to find a method to this madness, yet I cannot.
Haven't heard from their support escalation, or from NST.

I'll randomly get a host that advertises TLS, or pipelining, or both :wink:
Certainly not the behavior I would expect from Google, now that
they're doing government/education e-mail hosting.

4

PIPELINING and STARTTLS are unrelated issues, and both are currently
working as intended.
  
  - STARTTLS on MX is in the process of being rolled out and not visible
    from all client locations at this point.
  
  - PIPELINING is not offered under all circumstances.

Hope this helps, maw

5

Much appreciated. Could you let operators know where to look for the
status as it's rolled out? Or keep us updated here?

Since the client TLS (port 995) has been working for a long time, and the
https is becoming the default (we used to have to specify it ourselves),
getting MX transport secured is a good idea.