I work in higher education and we've been experiencing problems with Google
delaying or queuing email for delivery to our domain. Here's some truncated
email headers:
** Example 1:
X-Received: by 10.237.55.65 with SMTP id i59mr10986018qtb.62.1472137448952;
Thu, 25 Aug 2016 08:04:08 -0700 (PDT)
Received: by mail-qt0-f175.google.com with SMTP id u25so27419242qtb.1 for
<@***>; Thu, 25 Aug 2016 12:05:46 -0700 (PDT)
** Example 2:
X-Received: by 10.36.1.75 with SMTP id 72mr5275579itk.40.1472130531887;
Thu, 25 Aug 2016 06:08:51 -0700 (PDT)
Received: by mail-it0-f48.google.com with SMTP id x131so289116132ite.0 for
<@***>; Thu, 25 Aug 2016 11:50:42 -0700 (PDT)
In both of these examples, these emails haven't even left Google's internal
network yet; I'm getting blamed for these delays, however there is no delay
in receiving these emails after they leave Google's network.
Are other people having this same problem?
I've tested delivery to my network from many outside sources and all SMTP
requests go through without delay; this issue seems be exclusive to
Google-hosted and Gmail accounts and domains.
I was in contact with Google and after some convincing and detailed header
information, they acknowledged that they are having internal MX issues and
assure me that they will deal with the issue promptly.
Initially they did not even acknowledge that there was a problem, so it
took several tiers of support people to finally see the issue.
I look forward to the ongoing exchanges on the list.
With all due respect, it's S.O.P. for Nanogen to ask the list if anyone else is experiencing a particular problem with some carrier or another. So Nate's question is totally appropriate for this list. I know I've solved several problems by airing them here and getting insight from other list members.
Hi Mel, There's another mailing list called 'mailop' which is probably more appropriate for email related problems, than NANOG.
And in response to Nate:
I was in contact with Google and after some convincing and detailed header
information, they acknowledged that they are having internal MX issues and
assure me that they will deal with the issue promptly.
Initially they did not even acknowledge that there was a problem, so it
took several tiers of support people to finally see the issue.
I look forward to the ongoing exchanges on the list.
Useful to know, but John is right - as cited, working through Google's support process, got somewhere.
Further exchanges on NANOG are probably inappropriate. A group like 'mailop' probably has a higher care factor, however.
(I would also note that email delays that are demonstratably outside of your network (as headers will show) are very easily painted as something beyond your control, and the nature of email is very much 'best effort', so anyone playing the blame game needs a reality check. Just because email exchanges 'are often' near-instantaneous, does not mean they always will be.)
I was working within the limits of what I had available.
I apologize if people on the list consider a network and systems
administrator reaching out to peers for assistance with a particular
problem that is clearly network related is inappropriate for a network
operations group list that may or may not have Google or Google affiliated
employees or contractors on it.
In article <CALtoqtQkfEaDXnr1+4yzyDoyuweBG_+QyaQ7Ubhxtmv0JCnTmA@mail.gmail.com> you write:
I was working within the limits of what I had available.
Here's the subscription page for mailop. It's got about as odd
a mix of people as nanog, ranging from people with single user linux
machines to people who run some of the largest mail systems in
the world, including Gmail:
Im thankful Nate posted. Gmail isnt a small system that affects only a small
percentage of people worldwide, and therefore a perfect candidate for a mail-
specific list that many (and many nanoggers like me) arent part of, for lack of
additional bandwidth in life.
However, gmail not working (similar to 8.8.8.8/.4.4 or 4.2.2.2 not working)
shouldnt be on a mail-only or dns-only ops list im not part of: when 8.8.8.8
doesnt work, the complaints appear as "is there a power failure at your datacentre?"
to "my website is down!" - same deal with gmail, it's that big.
While I cant say exactly what that cutoff line is for mail and dns issues
being postable to nanog or not, I definitely know gmail is pretty much the top
of the pile (for now).
administrator reaching out to peers for assistance with a particular
problem that is clearly network related is inappropriate for a network
clearly network related? people have an interesting expectation of email -
expecting instant delivery. you might check their level of expectation....the
SLA etc define service availability but email delivery is pretty much 'best efforts
of all parties involved in the transaction' - ideally it gets there quickly...but
it could take up to 72 hours. google have several status dashboards that you can check/monitor.
generally, if you have an issue with a particular service on the internet, contact them directly.
dont use a 3rd party mail list - they *might* be aroudn on it but its not their official
service desk contact point
Thanks for all the feedback related and unrelated to the problem.
I'm aware of many available troubleshooting tools and considered this one
of them, but I've been shown that this, albeit appropriate, forum, was not
a good choice to solicit technical assistance.
Fun fact about letsencrypt certs, they expire after a month or so.
Looks like the site admin never noticed/cared to update it (since 2016), even though there's a nice little helper program to auto-update them that you can throw in a cronjob (or scheduled task, if you're into IIS) and forget about
