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

441–450 of 460 posts

Re: Gmail having issues

#441

Post by webbie917 »

dathinab wrote: post #221
petercooper wrote: post #24

Earlier quoted context omitted.

Yes. I email hundreds of thousands of Gmail users each week (yes, double opt in, they all want the mails!) and we immediately delete any user for whom any Gmail error comes up at all in order to keep a solid delivery record with them. Sounds like we might have deleted 80% of our list if we'd sent today..!

So new think to do: Quarantine addresses instead of deleting them and if for one provider most addresses fail don't give them another (maybe manually triggered) try later one. (And if no such thing is detected deleted quarantined mail addresses.)

My guess is that how most email service providers handle this - they don't actually delete the email and just have a flag on it - bounced, complain, unsub. This way the list owner can run an export and see all the status code.

Re: Gmail having issues

#442

Post by Triv888 »

RealStickman_ wrote: post #397
Triv888 wrote: post #367

Earlier quoted context omitted.

You need to at least hide your domain whois contact information if you are going to do this...

Many domain name registrars offer that as a service.

Yes but it often is not the default and as you know, most people dont change defaults (and there is also an extra monthly fee, which is a scam)

I know people here dont think its a scam but it is

Re: Gmail having issues

#443

Post by vlovich123 »

Jap2-0 wrote: post #155
noemit wrote: post #105

Earlier quoted context omitted.

They don't. The browser just adapts.

Desktop: https://mail.google.com/mail/u/0/ Desktop (plain HTML): https://mail.google.com/mail/u/0/h/ Mobile: https://mail.google.com/mail/mu/mp/

Is the plain HTML version under even the most basic maintenance? I was under the impression that was the old interface and they just kept it around because people liked it/slower countries.

The mobile vs desktop versions you posted are likely the same codebase with minimal (if any) differences. My understanding is that generally such things are accomplished transparently with flex layouts that automatically adjust to screen size

Re: Gmail having issues

#444

Post by agentdrtran »

nikanj wrote: post #317
sebmellen wrote: post #222

Earlier quoted context omitted.

I would be very interested to know this as well. I am trying to switch my company over to Google Workspace right now and support has been telling me my signup issues will be "resolved in 48 hours or less." What a joke. And this after we're leaving AWS Workmail because of bounced emails. No luck with signing up so far.

Heavily recommend you don't switch your company over to Google. Microsoft seems to understand that in the enterprise world you actually have to have support personnel, not just an opaque AI without chance for appeal

You can actually appeal things when you start paying.

Re: Gmail having issues

#445

Post by shmoogy »

webbie917 wrote: post #440
shmoogy wrote: post #189

Earlier quoted context omitted.

I would imagine since it's a known timeframe, domain, and error response, they can cleanly remove the suppression lists. I logged into our sendgrid and mailgun accounts and manually purged all the failed gmail records.

The hard bounce status might be stored outside of your lists. I am not sure customers can easily change a hard bounce status themselves. Do you mean you just deleted those records with intent to re-add to reset the status? On our BigMailer platform this wouldn't work as hard bounce status would get preserved.

We use SendGrid and Mailgun right now, and both of these expose the suppression list, email address, time, and reason code + description. In Sendgrid you can filter, and mass select to remove suppressions easily (which was great). In mailgun I had to export a CSV and just removed them manually as there was not too many across my accounts.

Customers generally cannot change this on their end as far as I can imagine -- this is on the ESP end and is a protection built in because you are sending from their IP / Server and they don't take kindly to that.

Re: Gmail having issues

#446

Post by 8fingerlouie »

schmappel wrote: post #434
8fingerlouie wrote: post #414

Earlier quoted context omitted.

> People will suggest running your own mail server, and if you have the time and energy then definitely do that. As a learning experience, sure, but most people are not prepared for what running a 24/7 mail service requires of them. First of all, a static, non-residential IP is likely needed. The big players will flat out refuse receiption if your IP is registered as residential, so that rules out hosting it from you…

> I purchased a lifetime subscription (limited promo offer) with mxroute.com. At the risk of stating the obvious, note that 'lifetime' refers to the lifetime of the company, not the customer. Which underscores the risk of buying lifetime subscriptions. And as much as I like the idea of avoiding recurring costs (I have a 'lifetime' Plex pass), it seems to me that these can't be sustainable for the company on the long…

I’m aware it’s the company’s lifetime (unless my expiration date comes up first), and I act accordingly with nightly backups of all mail.

It’s really no different than Google, where a single bad comment somewhere in their vast eco system can end up getting your account banned.

In my case I try to stay as far away from Google as I can with my everyday services. I’m also well aware that chances are extremely high that any email I send will make its way to Googles servers.

The “easy” solution would be to self host, and I do that to some extent, but as I work with system administration I really don’t want/need another day job. I’m actively looking for relatively secure, privacy aware and affordable cloud solutions for everyday use. I wrote affordable because nothing is free.

Re: Gmail having issues

#447

Post by mehrdadn »

dqv wrote: post #423
mehrdadn wrote: post #420

Earlier quoted context omitted.

No, I am quite explicitly not ignoring the spec. It quite deliberately says should not , not must not . If anyone is ignoring the spec here, it's you, not me. Should not is sound advice; it's telling you what you're supposed to do when you don't have a reason to behave differently . You know, like how you "should not" leave the lights on when you leave your room. Or—more pertinently here—how you "should not" assume e…

But the RFC isn't only for senders it's also for receivers, isn't it? That means there are two sides to the interpretation of what SHOULD NOT means. And in this case, senders have, due to experience, interpreted what Google does when someone SHOULD NOTs: - The sender SHOULD NOT send us the same sequence again when we reply 550, if they do they MUST go on our shitlist. Obviously it's not so binary and it takes retryin…

No, that's not a sane way to interpret this RFC for the receiver either. I already answered this, so you'll have to go back to my earlier comment (this might be my last comment as I won't keep repeating myself): any system (be it Google's or anyone else's) that penalizes you equally regardless of whether the recipient's addressed existed 1 day vs. never existed is just plain trash. A sender that attempts delivery to an address that accepted their email a day ago is obviously unlikely to be a spammer; there's no justification for treating them as one. It is absolutely unreasonable to interpret the sentence this way. Just as it's unreasonable to interpret "the mailman shouldn't knock a second time when he's told the recipient has moved" as "I should never open the door for the mailman ever again if he does so".

Re: Gmail having issues

#448

Post by Jap2-0 »

vlovich123 wrote: post #443
Jap2-0 wrote: post #155

Earlier quoted context omitted.

Desktop: https://mail.google.com/mail/u/0/ Desktop (plain HTML): https://mail.google.com/mail/u/0/h/ Mobile: https://mail.google.com/mail/mu/mp/

Is the plain HTML version under even the most basic maintenance? I was under the impression that was the old interface and they just kept it around because people liked it/slower countries. The mobile vs desktop versions you posted are likely the same codebase with minimal (if any) differences. My understanding is that generally such things are accomplished transparently with flex layouts that automatically adjust to…

> Is the plain HTML version under even the most basic maintenance?

I doubt much work is being done on it, but presumably they at least make sure it works; I mentioned it because a few posts up (edit: you) mention testing (rather than initial design) as the reason why having multiple designs is so difficult.

> The mobile vs desktop versions you posted are likely the same codebase with minimal (if any) differences....

It's entirely possible that they're derived from a similar codebase at some point, but what reaches the browser is significantly different - it's barely responsive, based on user-agent, and appears to be significantly different obfuscated blobs of HTML, CSS, and JS.

Re: Gmail having issues

#449

Post by vlovich123 »

Jap2-0 wrote: post #448
vlovich123 wrote: post #443

Earlier quoted context omitted.

Is the plain HTML version under even the most basic maintenance? I was under the impression that was the old interface and they just kept it around because people liked it/slower countries. The mobile vs desktop versions you posted are likely the same codebase with minimal (if any) differences. My understanding is that generally such things are accomplished transparently with flex layouts that automatically adjust to…

> Is the plain HTML version under even the most basic maintenance? I doubt much work is being done on it, but presumably they at least make sure it works; I mentioned it because a few posts up (edit: you) mention testing (rather than initial design) as the reason why having multiple designs is so difficult. > The mobile vs desktop versions you posted are likely the same codebase with minimal (if any) differences....…

I can’t speak to it but just because something is tested occasionally doesn’t mean the testing budgets are the same or serve the same purpose.

For example, the feature set required to support the HTML page could be frozen and the APIs backing them stable with no need to change. So testing isn’t really necessary. Alternatively, there’s just API changes being made to remove dependencies on deprecated code and so the testing coverage comes from the testing that happens of that API surface through other means. Finally, it could be that the HTML page is even fully staffed to support emerging markets. That’s a different budget potentially than the budget for the “rich” UI.

Again, my point isn’t to argue over the specific business pressures and practices Google has for their email UI. This requires a level of knowledge I don’t think either of us possess. All I’m trying to do is illustrate that there could be all kinds of pressures why the system is the way it is, but dismissing it as “laziness” or “stupidness” on the part of the designer is itself a lazy and stupid conclusion to make without concrete evidence. I generally assume that’s not the case and look for the incentives/pressures those people are under until there’s overwhelming evidence those people are actually stupid/incompetent (and even then, the question becomes what structures, incentives, pressures were in place to put those people in positions they shouldn’t occupy).

Post reply on HN