Google mail admin contact needed (STARTTLS capabilities issue)
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 -- Brent Jones brent@servuhome.net
On Fri, 03 Dec 2010 17:30:38 PST, Brent Jones said:
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
Equally troubling is the similarly random nature of PIPELINING, which doesn't even match the STARTTLS appearing or not. Definitely bad juju.
On Fri, Dec 3, 2010 at 6:48 PM, <Valdis.Kletnieks@vt.edu> wrote:
On Fri, 03 Dec 2010 17:30:38 PST, Brent Jones said:
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
Equally troubling is the similarly random nature of PIPELINING, which doesn't even match the STARTTLS appearing or not. Definitely bad juju.
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 ;) Certainly not the behavior I would expect from Google, now that they're doing government/education e-mail hosting. -- Brent Jones brent@servuhome.net
On Fri, 3 Dec 2010, Valdis.Kletnieks at vt.edu wrote:
On Fri, 03 Dec 2010 17:30:38 PST, Brent Jones said:
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
Equally troubling is the similarly random nature of PIPELINING, which doesn't even match the STARTTLS appearing or not. Definitely bad juju.
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 -- maw@{dont.,}beevil.org
On 12/6/10 6:58 AM, Michael Wildpaner wrote:
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
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.
participants (4)
-
Brent Jones -
Michael Wildpaner -
Valdis.Kletnieks＠vt.edu -
William Allen Simpson