Aside - I'm not an expert but systems like MailChimp will get very worked up if your list has lots of undeliverable addresses on it. This can trigger an audit of your list which prevents sending, etc. These audits seem to take quite a while, in my very limited experience.
So what you're saying is, if you're annoyed by "subscribe to our mailing list" modal popups, "doesno5exist@garbage.blah" is better than "jeff@amazon.com" ?
If you're trying to get the web site's mail server blacklisted, definitely.
Anyone else having issues in general with "the internet" over the last few days? The images on different websites I've visited don't load (e.g. twitter, bbc etc). When they do they load, they load verrry slowly
Oh, the internet is fine and happy.
The "internet" deserves these outages to make people - and CEOs, CIOs, etc - realize that in-house ~~engineering~~ sysadmins used to exist for good reasons.
People will suggest running your own mail server, and if you have the time and energy then definitely do that.
But the next best thing you can do is simply just use your own domain. That way, you can at least decide to migrate your email elsewhere. Don't use the free domains you get from things like gmail or other providers, because then you have to _change_ your email address, and not just your MX records.
We are using a gmail inbox to process some business-critical emails in bulk. I guess those emails will be lost forever? Thankfully, we have backups, but we will have to move them to the inbox or elsewhere to have them processed. Edit: As an update, we usually have at least 100 emails come in every hour, and I am seeing none since 4:02 pm EST
I wonder if Gmail is just not a very well maintained codebase. Here's an issue where old emails just become inaccessible. Not fixed for over a year and they've locked the thread so I'm starting to wonder if they actually deleted the emails by mistake. https://support.google.com/mail/thread/6187016 Maybe time to switch to a more reliable provider.
> Not fixed for over a year and they've locked the thread so I'm starting to wonder if they actually deleted the emails by mistake. Did you try pulling them down using the API tester?: https://developers.google.com/gmail/api/reference/rest/v1/us... Some of the internal formatting that Gmail uses has changed over the years, so more likely than not the API that parses the stored message for display in the Gmail UI is j…
I didn't but I did try Takeout and they weren't in it.
Either way my point is that this is a pretty serious bug and they haven't even acknowledged it! Not a good look.
> And honestly the practicalities of this situation and the risk-reward tradeoff seriously tilts toward repeating the request later regardless of what the RFC says. The world isn't going to end. That is exactly the thought process that leads to non-standard mess that we see numerous examples of. If you believe the standard is not robust enough to handle problems like this, first work towards a fix to the standard and…
> That is exactly the thought process that leads to non-standard mess that we see numerous examples of. I didn't suggest people should apply this thought process in arbitrary cases. I said it should be applied in this case. You can take any thought process that gives a good outcome in one situation and obtain a bad outcome by applying it to the wrong situation. That's not an indictment of the thought process. It's ju…
Ah I think I did not describe the repercussions of making exceptions (even if they are in highly specialized cases like this). If you allow yourself to make such exceptions, you diminish the motivation for you (or someone else) to fix the problem at the right place.
Most workarounds tend to live forever.
Gmail screwed up, but that's beside the point. We're talking about designing robust systems. You don't design a robust system by assuming nobody will screw up! Re: the RFC, note it says "should not", not "must not". That seems to suggest they acknowledge repeating might actually make sense in some cases. And honestly the practicalities of this situation and the risk-reward tradeoff seriously tilts toward repeating th…
My understanding is that should not means that you should not try to retry. If I do retry than the other party can rightfully claim that I am DDOSing their service, trying to send emails to deleted accounts or put me on a spam list. I do not think that ignoring the RFC and trying to cover up for Google is the best course of action here. Maybe, just maybe, this is the right time when people realise what does it really…
You "should not" repeat delivery in basically the same way the mailman "should not" knock a second time if he's told the recipient doesn't reside at the designated address. What "should not" means in these cases is: "knock only once, and assume you're being told the truth in the absence of further evidence to the contrary". But when you clearly saw the recipient reside there yesterday, it makes sense to try to knock and catch him again tomorrow. Because, you know, maybe something went wrong, e.g. maybe the person who opened the door didn't recognize the name (or whatever). At the end of the day, the mailman's job is to deliver the mail with minimal disruption, not to play hot potato with envelopes.
In lieu of an actual Googler, how about some educated speculation? It blows my mind that Google can even have problems like this. Aren't their apps highly distributed across tons of CDNs? Don't they have world class Devops people that roll out changes in a piecemeal fashion to check for bugs? How exactly can they have an issue that can affect a huge swath of their customers across countries? Insight appreciated.
You don’t really have to speculate, they disclosed yesterday that yesterday’s issue had to do with the automated quota system deciding the auth system had zero quota: https://status.cloud.google.com/incident/zall/20013#20013003
Thanks for providing this. It's funny to read the speculations when you have read the actual root cause :D
Well I guess the thing is left unanswered for now is why the quota management reduced the capacity for Google's IMS in the first place.