Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Gmail having issues

google.com

Post reply on HN
Print view View original

331–340 of 460 posts

Re: Gmail having issues

#331

Post by croon »

Sebguer wrote: post #207
toomuchtodo wrote: post #201

Earlier quoted context omitted.

Being down is okay. Returning an error message that results in the data being thrown away instead of being requeued is not. Block incoming smtp connections until your app layer is fixed.

Yeah, this is a particularly pernicious failure given how email works. Many mailing providers will just mark these as blacklisted, now, and lots of unsophisticated users likely won't notice.

I consider myself sophisticated enough, but my Bitwarden has 700 accounts, of which ~30% old ones are registered with a gmail address, and the rest are handled behind g suite. Granted that last bit might be partly my fault, even though I paid for it. But even for a "sophisticated" user, I have no easy way of knowing if any of these accounts have silently failed to function now, other than by the passage of time and eventually finding out.

Re: Gmail having issues

#332

Post by tshaddox »

ascar wrote: post #326
bayindirh wrote: post #308

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. 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 successful…

I think we’re just teasing at the notion that “permanent failure” isn’t a hard and fast distinction. I think some polite retry policy is not unreasonable even for the most explicit “permanent failure” response from a remote server. Imagine the most extreme example: hackers take over the remote server and make it respond with “permanent failure.” After a day, the legit owners regain control of the system. You can’t really argue that “the remote server never should have delivered that response unless the failure truly was permanent,” because clearly there was a mismatch between the apparent intent behind the response and the actual intent.

Re: Gmail having issues

#333

Post by marvion »

com2kid wrote: post #13
wenbin wrote: post #9

"Type: Permanent; SubType: General; Code: smtp; 550-5.1.1 The email account that you tried to reach does not exist. Please try 550-5.1.1 double-checking the recipient's email address for typos or 550-5.1.1 unnecessary spaces. Learn more at 550 5.1.1 https://support.google.com/mail/?p=NoSuchUser y128si147264pfg.177 - gsmtp"

This is pretty much the worst response possible. Hard bounces mean that email delivery services are going to start automatically removing, or at least stopping delivery to, entire slews of email addresses. A lot of clean up is going to be needed as a result of this. To add some more details, when using a 3rd party email delivery service, those services will either black-list or just outright remove email addresses wh…

Mailgun send a warning mail about increased bounces from our account. Sure, they know what's going on... but we send 4-5 digit mails per hour - it's a lot of bounces

That means I can't just resend the the emails blindly, because I'm too scared to trigger some sort of automatic suspension...

(I don't do this regularly, so I'm not familiar with all features... additional mail verification could help probably ....)

Re: Gmail having issues

#334

Post by onion2k »

ascar wrote: post #326
bayindirh wrote: post #308

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. 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 successful…

Google's user service should be able to tell the difference between a user's data not being available and a user that has been deleted or never existed in the first place. This issue is Google sending the wrong error code because of a problem on their end.

Mailing lists believing what an email provider tells them and acting in an overly cautious way is a separate issue.

Re: Gmail having issues

#335

Post by globular-toast »

I've been using Gmail since the invite only beta. In the past year I've had several occasions where important messages get somehow "lost" in the UI. The ones I've noticed are messages I've been waiting for, so I've gone and dug them out of "all mail" in most cases. They just wouldn't show in the normal inbox despite not being flagged as spam.

This outage has now convinced me I need a new email provider.

Re: Gmail having issues

#336

Post by pw6hv »

ascar wrote: post #326
bayindirh wrote: post #308

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. 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 successful…

But then why would Google's mailserver not know that it once delivered email to that mailbox?

If the protocol is stateful, why the state should be kept by the "sender" and not by the "receiver"? Being stateless removes this ambiguity in my opinion.

Also we should remember how bad is for spam reputation sending emails to a non-existent address and thus I would not blame it on the mailing list for being "overly cautious".

Re: Gmail having issues

#337

Post by tshaddox »

shaan7 wrote: post #321
mehrdadn wrote: post #253

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…

But here’s the thing: the standard (like all standards) is obviously not robust enough to physically prevent responses which incorrectly indicate permanent failure.

These incorrect responses could be caused by mistakes which the remote server admins could reasonably avoid, like software bugs. I understand not having much sympathy for that case, especially from an organization with no shortage of resources. But they could also be caused by, for example, hackers or governments exerting control over the remote server temporarily.

A standard which explicitly refuses to acknowledge these possibilities is not what I would describe as “robust.” An obvious better alternative would be to set some standards around what constitutes a polite retry policy.

Re: Gmail having issues

#338

Post by labawi »

ascar wrote: post #326
bayindirh wrote: post #308

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. 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 successful…

> doesn't fail completely but cannot access part of the data

If the a mail server can't tell whether a user/email is valid, it should either return a temporary failure or accept and queue.

Unless of course you're too big to fail, then you just do whatever you want.

Re: Gmail having issues

#339

Post by thaumasiotes »

onion2k wrote: post #334
ascar wrote: post #326

Earlier quoted context omitted.

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 successful…

Google's user service should be able to tell the difference between a user's data not being available and a user that has been deleted or never existed in the first place. This issue is Google sending the wrong error code because of a problem on their end. Mailing lists believing what an email provider tells them and acting in an overly cautious way is a separate issue.

> Google's user service should be able to tell the difference between a user's data not being available and a user that has been deleted or never existed in the first place.

This can't work; you can say that gmail's system should have a component that recognizes the difference between various failures, but that new component can itself fail. You can't solve the problem of "what if something fails" by saying "just add a new component that won't fail".

Re: Gmail having issues

#340

Post by himinlomax »

dataflow wrote: post #237
octoberfranklin wrote: post #209

Earlier quoted context omitted.

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

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

That's the standards-compliant way. Also I'd argue that spec'ing your code to handle cases where Google fails that badly is (was?) a poor allocation of LoCs.

Post reply on HN