
My account is sending spam emails - benpink
https://productforums.google.com/forum/#!topic/gmail/jtXGmic9dkc;context-place=forum/gmail
======
laurencei
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...](https://www.zdnet.com/article/spammers-delight-gmail-weirdly-
doesnt-see-spoofed-gmail-com-addresses-as-junk/)

~~~
laurencei
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

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

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

~~~
ahje
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....](https://www.ietf.org/mail-
archive/web/ietf/current/msg87153.html)

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.

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

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

~~~
notriddle
> 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...](https://en.m.wikipedia.org/wiki/Variable_envelope_return_path)

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

[https://www.parsemail.org](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."

~~~
timvdalen
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!

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

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

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

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

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

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

~~~
Bedon292
What do you use as your email service?

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

------
FuckOffNeemo
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;

~~~
foota
What do the DKIM and SPF checks say?

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

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

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

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

------
some1else
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](https://support.google.com/accounts/answer/3466521?hl=en)

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

------
kerng
Relevant security issue Gmail declined to fix over a year ago:
[https://www.zdnet.com/article/spammers-delight-gmail-
weirdly...](https://www.zdnet.com/article/spammers-delight-gmail-weirdly-
doesnt-see-spoofed-gmail-com-addresses-as-junk/)

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

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

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

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

------
SyneRyder
Another HN thread with more comments about this:
[https://news.ycombinator.com/item?id=16894593](https://news.ycombinator.com/item?id=16894593)

------
DanielDent
Probably unrelated, but telus.net's SPF record appears to authorize RFC6598
([https://tools.ietf.org/html/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.

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

~~~
jiveturkey
the login occurred awhile ago?

------
tlogan
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 :)

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

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

------
jimrandomh
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:".

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

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

------
4llan
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...](https://answers.microsoft.com/en-
us/outlook_com/forum/oemail-osend/receiving-phishing-message-in-behalf-of-my-
outlook/8201fe49-6a67-49a0-8f7e-b03f9a3bc786)

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

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

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

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

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

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

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

------
sengork
Some of you might want to see this as well:

[https://mashable.com/2018/04/22/google-gmail-spam-
telus/](https://mashable.com/2018/04/22/google-gmail-spam-telus/)

------
Tempest1981
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?

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

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

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

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

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

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

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

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

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

~~~
ryan-c
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.

~~~
ryan-c
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.

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

~~~
ryan-c
They appear to have quitely fixed it.

~~~
tetha
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](https://twitter.com/TELUSsupport/status/988060048843657216)

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

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

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

~~~
firewalkwithme
Yeah, I am also thinking app or phone

------
lukeholder
My father and I have been getting these all evening.

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

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

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

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

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

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

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

------
Screwtellus
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...](https://www.telus.com/en/support/article/ccts-and-cprst-feedback-and-
contact-information)

