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