Hacker Timesnew | past | comments | ask | show | jobs | submitlogin

Hi all,

Seth Vargo here from Google. Thank you all for taking the time to report the issue, and thank you for your patience as we fix it. Our engineering teams are aware of this issue and they are working to resolve it as quickly as possible. You should no longer see new spam messages appear in your sent box, and existing spam messages will be automatically removed over the next few days.



Perhaps you could encourage them (on our behalf) to write up a blog post afterwards? I know that many folks here would be curious to hear how they "resolve" this particular instance -- which effectively depends on a third-party with a misconfigured SPF record -- short of switching to "p=reject".


This is all the information I can provide at this time. Part of the Google SRE practice is to engage is post mortems, but they are usually internal-only. I’ll do some investigation to see if there’s more information we can share later, but unfortunately I can’t make any promises.


Can you comment on what the issue actually is? Is the issue with gmail or telus or both?


A little bit of both, really.

If Telus didn't have a misconfigured SPF record that caused host_check() to inadvertently (always?) return "pass", Gmail likely would have classified the messages as spam and the spammers probably would've quickly gave up.

On the other hand, one could reasonably argue that Gmail -- with all of their advanced algorithms and such -- should have been able to easily determine that these messages were "forged" (the absence of a valid DKIM-Signature: should have been a giant red flag, for example) and reject them, ideally, at SMTP time or, at minimum, immediately dump them into a user's folder. Likewise, a more restrictive DMARC policy (i.e., "p=reject") than what Gmail currently has ("p=none") would also have caused these messages to be rejected (although DMARC can potentially introduce other issues or unintended side effects).

Alternatively, you could blame it on the spammers.


I think there's a pretty solid argument that Google shouldn't be trusting Telus's SPF records. Just to take it to the extreme, suppose a spammer were to send emails through a gateway that they control. In that case, there would be no third-party with independent SPF records to rely on since the spammer would control them.

Google shouldn't need any "advanced algorithms" to tell that the message didn't originate from their own mail servers, or an SMTP client. I'd expect this ability from any email provider. I'd be shocked if this was possible at, e.g. Fastmail.


We will share more information as it becomes available and relevant.


This is exactly the kind of non-human PR speak that saturates Google's response to customers in all forums. Promises are half-made and always broken. There doesn't seem to be a will or desire to aggregate and manager customers' concerns.

I hope this time is different, and your team really does share more information as it becomes available and relevant. I doubt it, though, and will switch to a mail provider that I pay for and has good customer service (which is my inclination toward all Google services these days).


1. I am a human. I promise :)

2. I apologize if my response came off as “PR speak” as that was not my intention.

3. I am trying to manage customer concerns. It’s why I’m responding on HackerNews and similar sites.


As no one else has, I am going to thank Seth for making the time to comment here. He didn't have to, and as he just said, he is human too.


> I am trying to manage customer concerns

You do that by providing actual information, not by corporate zero-information talk.


You do realize he has to run the information he can and cannot give out by his higher-ups and possibly legal before he can reply publicly, right? Google isn't a small operation and is very vulnerable to lawsuits.

Also it's a Sunday.

The fact that he's even publicly responding here personally is already surprising to me.


As mentioned elsewhere in the comments they are still working on actually fixing the issue.

They have already acknowledged it, given some details about what they believe to be the root cause, and implemented a band-aid fix for the time being. I'm sure once they have fully investigated and resolved the issue they will provide more details.

At this point, giving out details based on what they think is the issue now may end up being partially or even fully incorrect and that doesn't do anyone any good.


Why do people consistently think that an employee gives a shit about whether you continue using a service?

I'm reminded of the summer I worked at the electronics booth at Target and people would threaten to take their precious business to Walmart.


> Why do people consistently think that an employee gives a shit about whether you continue using a service?

It's not that I think he does (or should) care. It's that his response reflects Google's public-facing attitude about their products, which are used for extremely sensitive personal issues. If that's not how things are internally, then I'm disappointed he isn't telling us (perhaps because he isn't allowed to).

He (and they) have a right not to care. I have a right to take my business elsewhere and let them know I'm doing it. If enough people speak, maybe it'll be a trend instead of an anecdote and Google will change the way they treat users/customers.


When I do customer support I care. That's actually what I'm paid to do in thise cases.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: