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...
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.
https://www.telus.com/en/support/article/ccts-and-cprst-feed...
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 -0400The 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.
----
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.
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.
So you could still send emails to your self and they would not get flagged as spam.
https://www.telus.com/en/support/article/ccts-and-cprst-feed...
They appeared just after I turned on my AWS instance briefly. So I thought it was related.
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.
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...
Bad design, period.
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."
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!
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.
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.
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;
DMARC failed and SPF shows that Telus.com was an approved SMTP relay for Google.com
Edit: posted into my original comment.
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."
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.
"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.
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.
"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.
"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.
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.
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 24 in my Inbox starting as 6:13PM (GMT-7).
from:(me@gmail.com|me@salesforce.com) to:(me@gmail.com) -{has:attachment}
Mark as read
Skip the inbox
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).
Mine are showing Telus in the relay as well. None show up in the sent folder, and I use 2FA on the account.
Their website is so abstract... sustainability, values, Health? No idea what they do.
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?
Gmail shows a weird "Mute" instead option -- never saw that before.
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
--f4f5e80f07d80f991b056a2936a0The 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)
exists:CL.%{i}.FR.%{l}.F2.%{o}.spf.nssi.telus.com
exists:CL.69.64.35.11.FR.reply.F2.telus.com.spf.nssi.telus.com
dig +short cl.69.64.35.11.fr.reply.f2.telus.com.spf.nssi.telus.com
127.0.0.1
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.
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
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.
https://www.telus.com/en/support/article/ccts-and-cprst-feed...