Live data from Hacker News

Gmail having issues

google.com

321–330 of 460 posts

Re: Gmail having issues

#321

Earlier quoted context omitted.

Nuance is not called for. The standard states that a 5xx SMTP error is a permanent error and "The SMTP client SHOULD NOT repeat the exact request" Gmail screwed up here, returning a 550 error, it's not anyone else's job to try to second guess that or retry in contradiction of the accepted standard. https://tools.ietf.org/html/rfc5321

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…

> 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 then implement the solution. Not the other way round.

Re: Gmail having issues

#323
It seems it's even worse for gmail to Gmail communication. Some of our company emails disappeared without any kind of bump information which causes a lot of frustration among our customers. I hope they fix it soon, it's a mess of massive proportion.

Re: Gmail having issues

#324

Earlier quoted context omitted.

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…

The terminology is well defined [0], so in this case, retrying is not ignoring the RFC.

It's a difficult one though, because as you rightfully state, covering up for Google is not the best course of action for the system as a whole, yet it's likely a good course of action for those users who didn't get their emails.

[0]: 4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label.

[1]: https://tools.ietf.org/html/rfc2119

Re: Gmail having issues

#325

Just got this from the ProtonMail team: > Dear ProtonMail user, Starting at around 4:30PM New York (10:30PM Zurich), Gmail suffered a global outage. A catastrophic failure at Gmail is causing emails sent to Gmail to permanently fail and bounce back. The error message from Gmail is the following: 550-5.1.1 The email account that you tried to reach does not exist. This is a global issue, and it impacts all email provid…

This is the Nightmare Scenario for mailing lists. Many of them auto-unsubscribe after a bounce.

I had this issue with GitLab. My email provider returned a permanent error one day (due to an issue on their end), so GitLab silently stopped sending any emails to my address. I checked my email in the preferences many times and had no idea it was blocked on GitLab's end. Eventually, after not getting any notifications, I contacted their customer service and was told of this hidden setting.

So if you are not getting any notifications from GitLab, even though your email is correct, I suggest contacting them and asking if you have been blocked due to an error.

Re: Gmail having issues

#326

Earlier quoted context omitted.

I said this in another comment but this seems like a naive way to react to an "address does not exist error" that they've already delivered to before. The only legit scenario in which that happens is when the user deletes the address, which is a rare event (pretty much always The underlying issue (wherever this occurs) seems to be lack of nuance regarding error codes when people try to implement robust systems. Diffe…

> I said this in another comment but this seems like a naive way to react to an "address does not exist error" that they've already delivered to before. Like HTTP, SMTP is also designed to be stateless so, in the first place, the remote server shouldn't return a permanent error in temporary failure scenarios. The default error should be 450: "Requested action not taken – The user’s mailbox is unavailable”, not "the u…

Your answer kind of misses the point GP was trying to make.

Google's mailserver could genuinely believe that the user doesn't exist, if the user service doesn't fail completely but cannot access part of the data and thus doesn't find a user record. In this case the returned "user doesn't exist" error is intended behavior of the mail server and the post you replied to still stands. If you sent to that email successfully earlier, it's much more likely that the server is responding erroneously than that the email actually got deleted.

Re: Gmail having issues

#327
post #291

Earlier quoted context omitted.

I said this in another comment but this seems like a naive way to react to an "address does not exist error" that they've already delivered to before. The only legit scenario in which that happens is when the user deletes the address, which is a rare event (pretty much always The underlying issue (wherever this occurs) seems to be lack of nuance regarding error codes when people try to implement robust systems. Diffe…

If Google and other major mail providers weren't opaque about this, then fine, but for me a single bounce is an immediate removal. I can't take the risk. I can't imagine the hell that would ensue trying to get through to Google to ask them to take me off their deliverability shitlist.

Has anybody ever received a reply from gmail's postmaster address?

I have good experience with them fixing issues related to their spam-related flagging for messages that are coming from our self-hosted email server, but never got any specific reply.

Re: Gmail having issues

#328
post #124

Earlier quoted context omitted.

I believe you mean: s/s\/his\/her/s\/his\/their/

s#s/his/her#s/his/their# also works and avoids awkward escaping. The first symbol after s is used as the separator. Works in vim, at least. In other words: s%s/s\\/his\\/her/s\\/his\\/their/%s#s/his/her#s/his/their#%

    awkward escaping
Or as I've seen it called, "leaning toothpick syndrome".

Re: Gmail having issues

#329

Just got this from the ProtonMail team: > Dear ProtonMail user, Starting at around 4:30PM New York (10:30PM Zurich), Gmail suffered a global outage. A catastrophic failure at Gmail is causing emails sent to Gmail to permanently fail and bounce back. The error message from Gmail is the following: 550-5.1.1 The email account that you tried to reach does not exist. This is a global issue, and it impacts all email provid…

This is the Nightmare Scenario for mailing lists. Many of them auto-unsubscribe after a bounce.

Oh no.

Re: Gmail having issues

#330
post #321

Earlier quoted context omitted.

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…

> 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 just an indictment of the person failing to correctly judge its applicability.

That said, by all means, do try and go fix the standard; I wasn't trying to imply you shouldn't do that.

Post reply on HN