My account is sending spam emails | Hacker News Reader

My account is sending spam emails

productforums.google.com

647 pointsbenpink143 comments

Exact same thing for me.

Noticed I was getting emails being sent from myself. More worringly was the emails appeared in my SENT folder. For 5mins I was freaking out thinking I was hacked, because I didnt think spoofing emails would show up in MY "sent" folder.

But I run 2FA, long complex unique password etc. I treat OpSec really highly. I checked all Google security settings, no unauthorised access, no apps using my account etc. Still did a password reset "just in case".

However one interesting part is after about 4 hours the emails automatically became marked as "spam" - and they disappeared from my "sent" folder simulatenously.

So it would seem the likely issue is someone worked out a way around the "Spam" setting for Gmail - and a by-product of not flagging spoofed emails as spam is Gmail marks them as "Sent" by you in the labels.

Seems this was flagged as a security risk over a year ago - and Google declined to fix? https://www.zdnet.com/article/spammers-delight-gmail-weirdly...

Here is a raw header for people smarter than me (I've changed my email to "my.email.fake@gmail.com":

    Delivered-To: my.email.fake@gmail.com
    Received: by 2002:a02:9d5d:0:0:0:0:0 with SMTP id m29-v6csp2463224jal;
            Sat, 21 Apr 2018 22:54:19 -0700 (PDT)
    X-Google-Smtp-Source: AB8JxZqeE/hqXWlPnOWNRXo4XX3nwZh/+NGaQwquAFr/o2KzBe7Ub8QYDmcPIiZPkY2UoHRI3eOH
    X-Received: by 2002:a19:c457:: with SMTP id u84-v6mr6519818lff.109.1524376459326;
            Sat, 21 Apr 2018 22:54:19 -0700 (PDT)
    ARC-Seal: i=1; a=rsa-sha256; t=1524376459; cv=none;
            d=google.com; s=arc-20160816;
            b=yNz7pv3/Uh4jUBqrFSpnrhROAQ6bdU0eiolhXCpHXodEBCygkRTsVIZiSPxU1e66PU
             +y1dJAT4q911YZE9Qb8jUKZ0yYuamvXY4NHGbN7hQzYR36ocZP4cuqrYZoLzrWzqWMjQ
             0PcYbDK5dgKO4yhJj4ymhDMW05YZATsYqmaianc6O4KmG0i1dPCvHu0Rjl4lWFfX1UEX
             jQK3/rA4Kqji/dHCqj6mHqiit2yzdj7XJTdoIiTdcBhWGoGOov1oCvpdzwQYRPCGe5qN
             A3l5e0qgqYY/aWmEWJ5Ia8vwvbWWQvbe+nH2AxQf0KArHXQ/ktQb8oBackZTljwQivgI
             ziIw==
    ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816;
            h=date:message-id:subject:to:from:arc-authentication-results;
            bh=e9D0rlZHq51n3B4mRj4EfKnNKsv8i1UrXVRpskBltKg=;
            b=QVTaX2wLGCYZzWS7YGqc7Ck1ZiLTbKEVNYjhOJqiJkqKqeR6r7dEhGMUFNpOGAQOYB
             Y5X/r0uktROpPceC8EzBnhLXtuVUJP2Q3Uje4QvTYLPrdMx8V1UvqJ4Wx6sxsHZR1tJB
             69rtTABGlOC2ZW3dE7uqiVtsIukJmb/HQDOItX5g+ifsyBy4A9KZbKWpU9agqaD1NOpG
             Rm7PnBzMAPbD0s02QBCeErZp+Irax0Gk7WzkGsJfO+GWjPMZN6DpWLvgS/vBRN0/Tz+B
             xLb3VO+EPN6bG2ZvGqRJZ4LlbQIVFpBQGRFAAqMQLDEZGKTFJxrA4uO3NMMRqbQno5IM
             cc6Q==
    ARC-Authentication-Results: i=1; mx.google.com;
           spf=pass (google.com: domain of reply@telus.com designates 91.203.70.10 as permitted sender) smtp.mailfrom=Reply@telus.com;
           dmarc=fail (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com
    Return-Path: <Reply@telus.com>
    Received: from rine.play-wto.com ([91.203.70.10])
            by mx.google.com with ESMTP id b69-v6si4041238lfe.13.2018.04.21.22.54.19
            for <my.email.fake@gmail.com>;
            Sat, 21 Apr 2018 22:54:19 -0700 (PDT)
    Received-SPF: pass (google.com: domain of reply@telus.com designates 91.203.70.10 as permitted sender) client-ip=91.203.70.10;
    Authentication-Results: mx.google.com;
           spf=pass (google.com: domain of reply@telus.com designates 91.203.70.10 as permitted sender) smtp.mailfrom=Reply@telus.com;
           dmarc=fail (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com
    Received: from gown.ShoppingBrew.com (ec2-13-58-85-245.us-east-2.compute.amazonaws.com. )
            by mx.google.com with ESMTP id n59-v6si5794010qtd.116.2018.04.20.00.37.14
            for <my.email.fake@gmail.com>;
            Fri, 20 Apr 2018 00:37:14 -0700 (PDT)
    Received-SPF: softfail (google.com: domain of transitioning nkhpw@google.com does not designate 91.203.70.10 as permitted sender) client-ip=13.58.85.245;
    from: Bitcoin Loophole <my.email.fake@gmail.com>
    To: <senderus@justvaluerate.com>,<senderse@justvaluerate.com>,<monsl@50-233-80-21-static.hfc.comcastbusiness.net>,<mz@traveldailymedia.com>,<gego@nih.gov>,<iscontact@rei.com>,<mz@wp.com>,<info@chadog.fr>,<info@autotrader.com>
    Subject: Are you still alone?
    Message-ID: <NkhPw@google.com=Mx.google.com>
    Content-Type: multipart/report; boundary="f4f5e80f07d80f991b056a2936a0"; report-type=delivery-status
    X-EMMAIL: <@googlemail.fr my.email.fake@gmail.com>
    Date: Sun, 22 Apr 2018 01:54:19 -0400

You could make a filter like this: The email is spam if FROM and TO address = my.email.fake@gmail.com AND Return-Path is not = my.email.fake@gmail.com

So you could still send emails to your self and they would not get flagged as spam.

The thing is I've used Gmail for nearly 10 years (give or take) - and I've never once had a spoofed email reach my inbox. Ever.

Something must have changed, most likely in the past 24 hours (give or take) to allow this to suddenly occur? Or someone's worked out a way passed the gmail spam filters or something.

Either way - this is clearly "new".

I’ve used Gmail for longer and I’ve seen it a lot over the years. What’s most likely changed is the volume at which the spammers are doing it, so you finally started seeing some come your way.

That would have been nice, but you can't actually filter by return-path in gmail :(

Yep, based on those headers it's the exact same thing discussed in the ZDNet and LinkedIn articles.

----

ETA: Just tried it myself, through my own mail server, and the headers are pretty much the same: the IPs are different, of course, and I didn't bother including extra forged Received: headers and such). This works beautifully -- message is in my Inbox (flagged as "Important according to Google magic.") and shows up under "Sent" as well.

After opening up "Show Original" in a new tab and then returning to the message, there's now a small banner (with a yellow background) at the top that reads:

> This may be a spoofed message. Gmail couldn't verify that it was actually sent from your account. Learn more.

The strange thing is the article is a year old? Why would it suddently be exploited now? I find it difficult to believe no one's tried until today?

Maybe some dark-hat's side project finally reached a major milestone and was released?

No idea.

Apparently someone just found out about it and decided to try it out -- it's obviously "new" to a lot of HN'ers as well.

It's probably been exploited for quite a while already, takes a certain time and threshold until these kinds of things fully bubble up to the public.

People who've been affected might not have noticed or cared enough to say/do something.

There is something strange about those headers. Are they all from the same email?

There are two Received: with by mx.google.com, and they are nearly two days apart. And there are two Received-SPF: headers.

Other than that, my guess is that the spammer has BCC'd you and put your email address in the from: header (oddly lowercase here). Gmail will put messages from you in the Sent folder (label) even when they are sent from outside Gmail.

The extra ones are probably made up by the spammer trying to trick Google's anti spam machinery.

When I was an anti-spam engineer 10 years ago, we saw this sort of tricks all the time. Basically the only headers you can trust are the ones inserted by your own infrastructure. DKIM does mitigate this somewhat, but of course has its own problems.

The last Received: and Received-SPF: headers are forged. It's pretty common for spammers to do that, apparently in an attempt to "trick" either spam filtering software or a person looking at the headers.

>Gmail will put messages from you in the Sent folder (label) even when they are sent from outside Gmail.

On the principle of least surprise, this would seem to be incomplete behavior. I bet every single person reading this was surprised.

It's not a bad place to put such mail, so I suggest that on its web and mobile interface, Gmail simply put some kind of badge for sent mail sent from outside Gmail or your devices. Example:

https://imgur.com/a/KEMf1HM

(Notice the ⓘ [circled i] in the first line.)

Source: I mocked above up from Google image search for "gmail sent folder" and an open clipart "information icon".

If you click on that i or hover it should mention that some of these messages were sent from outside Gmail or from your authorized devices but have been put in your Sent folder because your email address is in the from: field.

People notoriously won't know what a new badge means, and this being an uncommon scenario, no one will, panic ensues.

It might be better if such email was automatically marked as spam until the user marks it as good. If they keep doing that, then that send path should gain elevated trust. (I mean, they are using some ML system here right?) I'm imagining an anti-spam-campaign supervisor system that also tracks spam with some sort of soft hash (or ML), running across many user's email.

I can see this getting easily confused with emoji subject lines: http://www.emailmarketingtipps.de/2015/05/11/animated-emojis...

Yeah, this looks pretty straightforward. As I read it, it looks like telus.com has set up SPF records allowing people to send mail as @gmail.com via Telus' servers. That's fine. These messages are being sent with a "reply@telus.com" return address (the "envelope from"), but they are coming from gown.shoppingbrew.com and rine.play-wto.com (I don't get why there are separate received headers here from different sources -- usually multiple received headers form a chain of custody for the email, and this looks like two different sources somehow both sent the same message ... maybe one of those is forged?).

The only part of this that looks like a Google-specific bug to me is that I'm not sure Gmail should be dropping messages into your Sent folder that did not originate from your authenticated account. If you send a message using some other mail client that logs in to your Gmail account, or an app, or the web app, sure, but if a message just pops into your account with your address as the "from:" header, it shouldn't show up in your Sent label.

The rest of this is just email being as broken as it usually is.

SPF only checks the envelope-from. It doesn't check the other "from:" header. Anybody can easily clone anybody else's SPF records, so any service that allows you to route mail through them and has already cloned Google's SPF records (so that users can send mail through Gmail's servers using their @telus.com address) is vulnerable to this.

If SPF were changed to also check the other from: header, then it would break every single domain that uses Google's mail hosting services but hasn't updated their SPF records. So that's never gonna happen.

This is maybe the biggest reason I wish people would stop using Gmail for any kind of important mail services. The moment you do that, mail from your domain can be spoofed by any other outfit that also uses Gmail, and it will pass SPF, which means it'll cruise right through most spam filters.

DKIM can resolve some of this, but it comes along with a suitcase full of its own nightmares.

Neither DKIM nor SPF provide domain owners with a verifiable disposition policy and monitoring. You should deploy SPF, DKIM and DMARC together. At that point either SPF or DKIM may pass but if the passing SPF/DKIM domain(s) don't match the DMARC domain the message isn't authenticated. Unlike SPF, DMARC will load its policy using the From: header, and thus ensure alignment between envelope-From and From: header (for SPF), or DKIM domain and From: header.

You're right. I was thinking DMARC but wrote DKIM.

it does say DMARC=fail fwiw

DMARC could solve this problem, but it would break a lot of things reliant on forwards. When Yahoo set their DMARC policy to reject, there was quite a stir about it: https://www.ietf.org/mail-archive/web/ietf/current/msg87153....

In this particular case, it seems the major issue is that spammers got access to 69.64.35.11, which is included in telus.com's SPF record. In the end, this will hurt deliverability for legitimate emails sent with telus.com in the return path, and I suspect telus.com's customer service will have some explaining to do for their customers.

ryan-c comments below that the 'exists:' config at Telus allows any IP to send mail.

Spammers seem to be abusing this hole.

ARC is the new standard designed to fix the DMARC edge case with forwarding. It's relatively new, though, so adoption isn't nearly as widespread as SPF, DKIM, or DMARC.

Gmail's sent folder isn't a sent folder in the traditional sense. It's a label that just filters mails based on the "from" address.

That's a bug. Does anyone disagree?

I disagree because your sent mail also appears in your inbox and vice versa as part of threads.

It's non-standard, for sure, but it's "by design" and I suppose they can do whatever they want on their own platform. I'll stick with my IMAP4-compliant mail server, though.

It was always like this and I never considered it as bug.

Are you sure about that? I have gotten many spoofed spam emails before but I've never seen them appear in my sent folder before. Furthermore when I search "from:[my email]", I see a different listing than when I look in the sent folder.

I have a very short gmail address so I get _loads_ of spam daily. The above is actually correct. Emails from my address, even though they are spoofed will show up in my Sent folder until I mark them as Junk. I just checked with the 3-4 spams I received last night all all where in Sent.

Then that is really stupid. I want an email client, not a gmail client.

Re: others forging your domain by using Gmail - this is only true in narrow edge cases like this one (which appears to have been relatively quickly fixed by Gmail).

In practice, the Gmail and G suite UIs provide enforcement mechanisms to ensure you own a domain/address before allowing you to send from it.

Does it potentially open you up to spoofing if another loophole/exploit like this is discovered? Sure. But as risk factors go, depending on who you are, that's probably relatively low on the list.

Adding to this. You can only use Gmail for sending with your own domains when you have 2FA enabled.

Not really. It also works if you also lower your account security setting to low to enable 'Less-secured app' to login.

Sure that is still available? Pretty sure this is disabled for a few years now. At least it was when I checked last time.

It’s clearly failing DMARC there. Very odd.

Hey guys, you can contact tellus via this link. You don't need to he a customer for this.

https://www.telus.com/en/support/article/ccts-and-cprst-feed...

Crazy, I'm glad it's not just me. Looking in my spam and there's dozens of them.

Same too. The odd thing for me is that the client address (from the original text) was an AWS address. Only two appeared in the main inbox. More were sent straight to spam.

They appeared just after I turned on my AWS instance briefly. So I thought it was related.

wow... reading this thread is scary. Google is a joke; my humble advice would be to close your accounts and pay for a better service, life Fastmail or Protonmail.

Hey guys, you can contact tellus via this link. You don't need to he a customer for this.

https://www.telus.com/en/support/article/ccts-and-cprst-feed...

When you changed your password did you receive a google code from a 614 area code number?

I think this is exactly what is going on. Gmail doesn't use IMAP folders in the traditional sense, it uses labels. For something to appear in your "Sent" folder, it only has to show your email address as the sender. Since it's quite common for spammers to use your email address as the "From" in spam messages sent to you, Gmail automatically throws it in your Sent "folder" by way of a label.

I freaked out at first when my Fastmail account started getting spammed seemingly by my old Gmail account (I no longer use Gmail but I kept the account active and forwarded to Fastmail to catch anyone I forgot to update with the new address). I logged into Gmail and immediately changed my password, made sure I didn't have any third party app access, and turned on 2FA.

After seeing this HN piece and reading through the first few messages in the Google product forum, I realized it was typical spam that was breaking through Google's spam filter and freaking everyone out due to Google's handling of the Sent folder/label.

Don't freak out about them being in your Sent folder. Remember that Gmail doesn't have "traditional" mail folders -- just a huge pile of all your e-mail messages with "labels" attached to them. Apparently Google decides that if the From: address is yours, then you "sent" the message.

Note that in SMTP there are two "from addresses": the envelope sender (which you don't see) and the "From:" address/header (which you do see) that everyone is familiar with. In most (but not all) legitimate e-mail, they will be the same.

In these cases, your e-mail address is being used in the "From:" and "To:" headers but a different address is being used in the envelope sender (which is the one that the MTA uses).

Google does seem to be checking SPF correctly (i.e., according to RFC, which says to use the envelope sender) -- since (it seems that) the result of check_host should be "softfail" and the RFC says that one "SHOULD NOT" reject a message based on that... but Google apparently logged "pass". Odd.

---

ETA: See a comment from ryan-c below about the funky "exists:" mechanism in Telus' SPF record; it explains why check_host() passed.

> Apparently Google decides that if the From: address is yours, then you "sent" the message.

Bad design, period.

> In most (but not all) legitimate e-mail, they will be the same.

Just to be clear, most automated emails from major providers have them different. This is because, while the From header is shown to the user, the envelope sender is sent bounces.

So companies like Google, SendGrid (used by GitHub), and MailChimp set up special "bounce handler" addresses as the envelope sender to detect if there's a problem sending you email.

https://en.m.wikipedia.org/wiki/Variable_envelope_return_pat...

Some of you posting raw message sources might find a website I built useful:

https://www.parsemail.org

From my about page:

"Paste the raw source of an email into the form on the front page. The email will then be parsed, decoded, separated into its various MIME parts, and displayed in an easy to view fashion. Image attachments will be displayed as images. HTML parts will be rendered in webkit (with javascript and plugins disabled) and then also displayed as an image. IP addresses in headers and message bodies will be identified and highlighted along with a flag representing their origin country. Hostnames and email addresses will also be identified and highlighted."

Wow, that's really useful!

Whenever I get a weird/suspicious email the first thing I do is look at the source but the amount of info in there (and different encodings) can make it hard to grasp what's going on.

I'll definitely use this in the future!

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.

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

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).

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.

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

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

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.

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

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.

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.

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.

Just wanted to say, the top response on the google forum is exactly why google needs real support and not community members copy-pasting “solutions”.

Stories like this make me glad I use an email service which values me enough to have real humans who actually work there answer my support requests.

What do you use as your email service?

FastMail. I've opened a handful of support tickets and always gotten an answer within a few hours.

https://support.google.com/mail/answer/50200?hl=en

I think that link was pasted in sarcastically - Microsoft “support” style, where someone is paid to keyword-match your question without bothering to understand your question.

My house mate has had the same issue today on both of his Google accounts. He is both the sender and recipient and there were several other nonsensical email addresses being CC'd in.

SMTP headers show the emails are relayed from Telus. I'll provide the SMTP headers when I get home.

= = =

No unauthorised attempts to log in from third party sources, seperate passwords and MFA on both services.

It doesn't seem to me that the accounts have been compromised, instead the emails are spoofed. They have all been forwarded from Telus.com. The forum OP posted shows everyone else has the same issue.

Both accounts were sending hundreds of emails today and Google flagged the emails as likely having not been sent by him, but still did not place them in an appropriate spam filters and allowed them through to his inbox?

Edit:

= = = = =

I won't bother adding my headers now, the others that have even added theirs are almost identical to our own, here's a snippet of some one who posted below:

SPF and DMARC results

ARC-Authentication-Results: i=1; mx.google.com;

spf=pass (google.com: domain of reply@telus.com designates 69.64.35.11 as permitted sender) smtp.mailfrom=Reply@telus.com; dmarc=fail (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com

Authentication-Results: mx.google.com;

spf=pass (google.com: domain of reply@telus.com designates 69.64.35.11 as permitted sender) smtp.mailfrom=Reply@telus.com;

dmarc=fail (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com

Received: from gown.ShoppingBrew.com (ec2-13-58-85-245.us-east-2.compute.amazonaws.com. ) by mx.google.com with ESMTP id n59-v6si5794010qtd.116.2018.04.20.00.37.14 for <<myemail@gmail.com>>;

Received-SPF: softfail (google.com: domain of transitioning nkhpw@google.com does not designate 69.64.35.11 as permitted sender) client-ip=13.58.85.245;

What do the DKIM and SPF checks say?

Same as the others that have been posted.

DMARC failed and SPF shows that Telus.com was an approved SMTP relay for Google.com

Edit: posted into my original comment.

This is spoofed email, with you also being the recipient as far as I can tell... Am I missing anything else in this matter? If not, this isn't new.

EDIT from below: "If I remember correctly, if you are the recipient of an email from "yourself" Google automatically puts it in the sent items label as well."

They are reporting the items in their sent items though...

If I remember correctly, if you are the recipient of an email from "yourself" Google automatically puts it in the sent items label as well.

My guess is the sent folder is just a label where from-address matches one of your emails. Spoofing the inbox in the manner mentioned here will naturally also fool the sent folder.

Read the thread before you comment!

People are reporting these messages are in their sent mail folder!

Now it's possible that gmail makes it looks like it was "sent mail" if it receives a message "from you" even if you didn't send it, but it's also possible that google has been hacked in a big way.

And some of the people reporting this are knowledgeable people who know what spoofing is, and who have good unique passwords and two-factor enabled.

I did read it before I commented. I just proved what I said below (before you commented).

"If I remember correctly, if you are the recipient of an email from "yourself" Google automatically puts it in the sent items label as well."

Google threw it in my Sent Items despite me not sending it from gmail itself.

Most people don't realize some services you "Logged into with Google" can also send emails in your name. I didn't come across anyone checking authorized apps in that thread. While this appears to be a spoofing issue, I suggest pruning the list of authorized apps frequently: https://support.google.com/accounts/answer/3466521?hl=en

I checked that and the only one that had email access was my Windows desktop. This led me to assume my PC had a virus, until I saw this thread.

Most people "don't realize" that because it's totally false. Only holders of specific OAuth scopes can use the Gmail API. The "basic account info" access that login with Google grants is not sufficient.

Relevant security issue Gmail declined to fix over a year ago: https://www.zdnet.com/article/spammers-delight-gmail-weirdly...

I'm not sure how they would fix that, assuming that's even a bug. The email protocol is completely unverified, anyone can send the header they please, including spoofed From: headers. The GMail client itself even allows it, when you compose a new email you can change the "From" to anything. That's actually a rather useful feature when you have several addresses redirecting to one gmail address.

So it's not so simple. You could use DMARC to tell mail servers which honor DMARC to drop all e-mails that have @gmail.com addresses that don't come from gmail.com servers. In fact, this is how @google.com e-mail addresses are treated, and I believe this is a setting which G-Suite administrators can set up for their domains.

BUT. It comes with a downside. Suppose you want to send e-mail from your Linux laptop, or from a Linux mail server you control, without hard-coding your account password in a text file so you can send e-mail via a GMail server. Or suppose you want to subscribe to a mailing list which rewrites the subject line to include the mailing list name. DMARC breaks all of this. Horribly. So yes, it's more secure, but it comes with a massive cost.

What this means, for example, is I recommend people who work at Google, and who want to interact with either IETF mailing lists or the Linux-kernel mailing lists at vger.kernel.org to send their patches and PULL requests using their @gmail.com address. If they send it using their @google.com address, the same security settings that will prevent this spammers from "faking" e-mails that didn't come from gmail servers, will also break git send-email (unless you want to save your password into at text file --- which is against policy and common sense) and it will break traditional mailing lists.

I got 2 of these a hour ago.

"This may be a spoofed message" Google says, I clicked spam even though it's from myself. It was to me and a bunch of other emails. Wasn't in my sent folder though and no one else has accessed my account.

"Sexy Girls Asian Girls Looking for US Men" is the subject and says it's sent from "----------------- via telus.com"

Really odd, seems to be some ISP in Canada and I live in the USA... Wonder how they got my email.

I encountered the same thing, but different adverts.

Weird. My wife and I got the same email.

Telus is a phone/ISP company, they're pretty much uninvolved other then the ability to send emails from a @gmail.com address for their customers needs. Spammers are just utilizing that for malicious purposes with spoofed headers. As for how they got your email, the spammers could very well be working from the US too, Telus is just a tool. But then again on the internet boundaries matter less and they could be halfway across the world and got your email from a random online leaked list.

Another HN thread with more comments about this: https://news.ycombinator.com/item?id=16894593

Probably unrelated, but telus.net's SPF record appears to authorize RFC6598 (https://tools.ietf.org/html/rfc6598) IP space:

"v=spf1 ip4:199.185.220.0/24 ip4:198.161.157.0/24 ip4:198.161.156.0/24 ip4:204.209.205.0/26 ip4:209.171.16.0/24 ip4:100.64.0.0/24 mx ?all"

100.64.0.0/24 is within 100.64.0.0/10

Either I'm missing something, or Telus appears quite confused about the purpose/nature of SPF.

I woke up this morning to several new labels in my gmail to delete all emails for "bank" "card" "paypal" etc, and paypal was hacked with purchases.

But my gmail has zero new logins, my 2fa wasn't triggered, etc.

How does a hacker create labels to delete my email but not register a login attempt or trigger my 2fa? I wish I was able to contact google.

EDIT: my only guess was accessing my PC where logins are saved, but I sleep in the same room and I don't think ninja spies broke in. Remote login? Seems farfetched.

the login occurred awhile ago?

The emails are spoofed. The bug is Google is labeling emails with "Sent Mail" because "from:" header matches your email.

I think the "bug" was that not all "Received-SPF" headers are not correctly checked (only first one was checked). However, I'm not even sure if this is a bug since I'm not sure if their migration of emails into G Suite will work if they start not trusting "from: header.

The real bug is probably that email is not marked as spam :)

I had some of these earlier today as well. Mine wasn't from telus however, it was from some .science account. I use a password manager and have 2FA enabled, but I quickly switched my password just to make sure. Sure enough, a few hours later I got another one, for about 5 in total. They seemed to have stopped however.

Something funny I've noticed is my business account is not receiving any spam but my free gmail account is.

If you have a suspicious or spoofed email and you want people to analyze what happened, it helps a lot if you include the full headers. To do this in gmail, open the menu and pick "Show Original". Particularly useful are the lines that start with "Received:".

This strategy seems odd. If they had simply omitted the spoofed sending email address from the To:/(B)cc lines, we'd never had seen them in our inboxes... right? Why call early attention to yourself?

I had 24 in my Inbox starting as 6:13PM (GMT-7).

Maybe that’s part of the technique to trip up Google’s spam filters, as Google might have assumed that spammers would never bcc the sender and thus treat such mails as more likely to be legitimate.

I have this problem with my Hotmail/Outlook account for almost 5 years and Microsoft team don't even understand what's going on. - https://answers.microsoft.com/en-us/outlook_com/forum/oemail...

Same thing here! I woke up this morning and saw that I've sent out spam emails (about 15 of them) with my email address via telus and receive responses in my inbox.

To temporarily alleviate this issue, I created the following filter to stop my phone ringing constantly:

    from:(me@gmail.com|me@salesforce.com) to:(me@gmail.com) -{has:attachment}

    Mark as read
    Skip the inbox

Until I added this rule I was being pinged once a minute since lunch time yesterday.

This ignores: emails from me, or some sales force spammer they were using, to me, that doesn’t have an attachment (so I can still email myself files).

I had the same issue tonight. It did not appear in my sent folder, however, and was sent from the same “reply@telus.com” account that everyone else reports. The most recent one (of 5 sent so far) was sent 2 minutes ago. I changed my password an hour ago - but as I suspected that didn’t help because these aren’t being sent via compromised accounts. Someone is using an SMTP server and just spoofing the sent from address.

I had the same thing happen today. At least 6-8 emails in my inbox over the course of an hour or two, from my email address. Mostly ads for "dating" sites with photos of scantily-clad women. The to list includes my address, as well as about 8-10 other addresses, including one at rei.com and another at nih.gov.

Mine are showing Telus in the relay as well. None show up in the sent folder, and I use 2FA on the account.

I wonder if telus did this to allow people using their email system to use Google calendar to send reminders.

Who is Telus? I'm seeing the spam sent from me via Telus, but I don't use Telus, afaik.

Their website is so abstract... sustainability, values, Health? No idea what they do.

Telus is one of the major Canadian telecom companies, and one of the largest ISP in Canada. As such they provide @telus.com email address, and my thinking is that this is why they would add google.com to their SPF record, so that people registering google accounts with their telus email address could receive reminders sent by google but with the user's email address in the from field.

Some of you might want to see this as well:

https://mashable.com/2018/04/22/google-gmail-spam-telus/

So who is Telus, and why are they special?

Is it Google who has a relationship with Telus -- because I'm pretty sure I don't.

Can Google prevent Telus from doing whatever they're doing? Or is Telus just the victim/conduit of the real spammers?

Telus is a phone company. They presumably deal with text/email stuff through their phone services, and they presumably have some sort of interactions with Gmail as a result. This isn't Telus doing it, it's just spammers utilizing the ability for Telus to send emails to customers. From someone else in the thread: "it looks like telus.com has set up SPF records allowing people to send mail as @gmail.com via Telus' servers. That's fine. These messages are being sent with a "reply@telus.com" return address (the "envelope from")". Telus is just being maliciously used for something it rightfully offers to customers.

Telus is a big telecom company in Canada: landline, mobile, ISP, TV. Other big companies comparable are Roger’s and Bell. Telus has a wikipedia page.

A bit unrelated but requiring login to just read a forum thread is not good. :( I don't want to login to google again on this device therefore I haven't seen the thread.

Wow. I've been facing this since yesterday night, didn't know the entire internet is facing this problem. There's still no official response from Google it seems.

If the emails are (spoofed as) from me, and I tell gmail to mark them as spam, does anything bad happen?

Gmail shows a weird "Mute" instead option -- never saw that before.

I’ve had similar problem a long time ago with my yahoo account. (Password change didn’t help) So, I cleared my yahoo contact list and that stopped the spam.

I’ve been debating leaving Google Apps for months now and oddly enough this is the straw that broke the camels back. Will be migrating to a new host today.

This happened to me today as well. I also run 2FA. Did not see any suspicious devices or activity in the log, other than the sent emails.

Crazy. This was happening to me today as well. Tonnes of spam from my email, but being sent to these weird blanket emails. Worrying.

I had the same thing in my account (same relay through Telus). Here're my headers

  Delivered-To: <myemail@gmail.com>
  Received: by 10.74.77.209 with SMTP id p78csp1252253ood;
          Sat, 21 Apr 2018 19:48:30 -0700 (PDT)
  X-Google-Smtp-Source: AB8JxZrx9G5VDRbvtvoQWl5sUYm3w7k1TQ5f+Sd3g74T+fFLkrWnEV7qhVmFTr7X0pBQCd5q+my5
  X-Received: by 2002:a6b:6f01:: with SMTP id k1-v6mr16819882ioc.221.1524365310928;
          Sat, 21 Apr 2018 19:48:30 -0700 (PDT)
  ARC-Seal: i=1; a=rsa-sha256; t=1524365310; cv=none;
          d=google.com; s=arc-20160816;
          b=Ry11M99U7ldzJoPvejp48dePTM/MlHI4xQTc2jrwZR3CeugDTEfUpA783hpLnaw0gg
           NCsTVBtObV1GYioVRQDSxWAczHFiPQGld0u5afD+xpb2eGpr7/eZxTwvJPHYpl/FLwNk
           pNXj3w7VObPIyj43K4Zkf9rgNF1TRCYx4RbRvesaBcHMADJS1vDRB5TAsJ8DV6dF7gOB
           +O59qvWZzg0nE265rBJ1b8fWXWuQb4KpdVdwolZ3T3fqFDGY2cHnsmZMWTRzcjsLFWuD
           86+fIW1ccWf1eIjNh3LvecY6B0zzW9LjfgQw+0IvrkEdbwDc1EAbNhWI6kilOPIsDJGD
           Lzng==
  ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816;
          h=date:message-id:subject:to:from:arc-authentication-results;
          bh=4oe6QhhObsHLHbjLfsZs16iUEYy2rMdtn0ju3umolqQ=;
          b=FoRwZqhc5F7H6pItUYqZ2y/OxsZQkWNDEhj4Ody6uJ1vaC3DzUbXqa4mw1Pb0AgfZe
           QaBcfWaloNJJXBBWIjERShMCo3wYb/wcXtdOlT4x3o7uhAxQJ5sGBQqnVQ4QfH/d9pIh
           DaqTXWcaEieX3tsVDXO8UtZviUTsA7FjO2YGkk/f4rj1K9VOkxqiyECGyQf1uDAI/55d
           7O1t76oCpYr/qyAAx2YGBnz87ShD4bORPOg8iHwb9f4zAq7tfwOoF/Z3blPFR8EA2Xam
           q9x+2OIRsA2oX+t/HNsdrYOkWPkYwhiHwptl0vQZDHZn3E4Uue8DofG5sRLoAFM1rVYJ
           e5RA==
  ARC-Authentication-Results: i=1; mx.google.com;
         spf=pass (google.com: domain of reply@telus.com designates 69.64.35.11 as permitted sender) smtp.mailfrom=Reply@telus.com;
         dmarc=fail (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com
  Return-Path: <Reply@telus.com>
  Received: from shop.eseonew.com (static-ip-69-64-35-11.inaddr.ip-pool.com. [69.64.35.11])
          by mx.google.com with ESMTP id v64-v6si7872516iof.146.2018.04.21.19.48.30
          for <<myemail@gmail.com>>;
          Sat, 21 Apr 2018 19:48:30 -0700 (PDT)
  Received-SPF: pass (google.com: domain of reply@telus.com designates 69.64.35.11 as permitted sender) client-ip=69.64.35.11;
  Authentication-Results: mx.google.com;
         spf=pass (google.com: domain of reply@telus.com designates 69.64.35.11 as permitted sender) smtp.mailfrom=Reply@telus.com;
         dmarc=fail (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com
  Received: from gown.ShoppingBrew.com (ec2-13-58-85-245.us-east-2.compute.amazonaws.com. )
          by mx.google.com with ESMTP id n59-v6si5794010qtd.116.2018.04.20.00.37.14
          for <<myemail@gmail.com>>;
          Fri, 20 Apr 2018 00:37:14 -0700 (PDT)
  Received-SPF: softfail (google.com: domain of transitioning nkhpw@google.com does not designate 69.64.35.11 as permitted sender) client-ip=13.58.85.245;
  from: ABC Shark Tank <<myemail@gmail.com>>
  To: <senderus@justvaluerate.com>, <senderse@justvaluerate.com>, <monsl@50-233-80-21-static.hfc.comcastbusiness.net>, <mz@traveldailymedia.com>, <gego@nih.gov>, <iscontact@rei.com>, <mz@wp.com>, <info@chadog.fr>, <info@autotrader.com>
  Subject: Exclusive Limited Time Online Offer Shark Tank Success Story
  Message-ID: <NkhPw@google.com=Mx.google.com>
  Content-Type: multipart/report; boundary="f4f5e80f07d80f991b056a2936a0"; report-type=delivery-status
  X-EMMAIL: <@googlemail.fr <myemail@gmail.com>>
  Date: Sat, 21 Apr 2018 22:48:30 -0400  

  --f4f5e80f07d80f991b056a2936a0

Some parts of these headers look faked to me, in particular, the bottom most Received is definitely faked, and probably also the bottom most Received-SPF and Authentication-Results.

The current SPF records for telus.com don't seem to allow sending by 69.64.35.11.

Did someone figure out how to trick gmail into accepting bogus headers indicating the SPF passed?

Also, the timestamps on the received headers differ by a lot. This one:

    Received: from gown.ShoppingBrew.com (ec2-13-58-85-245.us-east-2.compute.amazonaws.com. )
            by mx.google.com with ESMTP id n59-v6si5794010qtd.116.2018.04.20.00.37.14
            for <my.email.fake@gmail.com>;
            Fri, 20 Apr 2018 00:37:14 -0700 (PDT)

appears to be identical (except for the email address) for the two sample sets of headers in the thread.

mxtoolbox indicates that SPF for telus.com redirects to "_spf_telus_com.nssi.telus.com", which designates "_spf.google.com" as an authorized sender.

That's why the SPF check doesn't fail.

However, in the year 2018 I'm shocked that Gmail would put messages that fail dmarc into users' inboxes.

It's not being sent from any of the IPs listed under _spf.google.com, though.

Telus has this entry:

    exists:CL.%{i}.FR.%{l}.F2.%{o}.spf.nssi.telus.com

Reading RFC 7208, that would be expanded to

    exists:CL.69.64.35.11.FR.reply.F2.telus.com.spf.nssi.telus.com

which means if that any record exists at that name, it will pass.

    dig +short cl.69.64.35.11.fr.reply.f2.telus.com.spf.nssi.telus.com
    127.0.0.1

trying a few other values, it seems that telus.com is saying ALL IP addresses are allowed to send for it.

It seems like everything in the zone "spf.nssi.telus.com" resolves, regardless of further DNS labels. So yeah, I'd say every host with any IP is allowed to send mails as anything from telus.com. That's a bit unsettling.

They appear to have quitely fixed it.

Indeed, the DNS records are gone. They had a tweet[1] 1 hour or 2 ago how they are working on it. I guess someone got phoned on his sunday to fix it. I'm hoping for a further update from their side what happened.

1: https://twitter.com/TELUSsupport/status/988060048843657216

Yep - I received precisely the same message, among 3 others. They all had the same "Message-ID" header as your example.

This part is interesting:

  Authentication-Results: mx.google.com;
         spf=pass (google.com: domain of reply@telus.com designates 69.64.35.11 as permitted sender) smtp.mailfrom=Reply@telus.com;
         dmarc=fail (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com

I had thought that as of early 2017 that had changed the DMARC policy to p=REJECT which would basically reject any attempts at spoofing gmail.com in the From: field. It seems as if someone suddenly (maybe accidentally) reverted that change?

It appears to be validating the envelope sender (reply@telus.com) rather than the from address, per the spec.

The thing is, telus.com doesn't have a DMARC record, and thier SPF record doesn't include 69.64.35.11. This header might be fake. Gmail does currently have a DMARC record that says p=none sp=quarantine. The 'sp' value only applies to subdomains, so the "none" (no action) policy should be used.

Edit: I just verified that gmail's dmarc has had p=none for a long time.

This is pretty alarming. Is there another service to switch to that's as reliable and more generally safe as Gmail?

Great to see this! I was getting mad at all this SPAM coming from myself today!

Perhaps it's a browser extension/plugin that got hacked?

Yeah, I am also thinking app or phone

My father and I have been getting these all evening.

Ditto here. 1Password generated pw, 2fa, etc.

Yes my gmail spam has gone nuts!!!! Wtf has happened

From the way the emails are sent, I bet it's an Android security hole.

What about those of us who don't use Android phones?

I remember when my mom's machine started sending spam with my name in the address field. Clever Trojan.

There was an attack going around many years ago that was basically a spam email that had code embedded in it, which would hack your browser, causing you to send out more spam email when you logged into your account. I assume this is the same sort of thing.

Nope. This is just Gmail appending the "Sent" label to an email that you received from "you". You didn't actually send it, it was just a spoofed From header.

Hey guys, you can contact tellus via this link. You don't need to he a customer for this.

https://www.telus.com/en/support/article/ccts-and-cprst-feed...

Reply on news.ycombinator.com