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 <[email protected]>;
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. 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.1: https://twitter.com/TELUSsupport/status/988060048843657216
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 [email protected] designates 69.64.35.11 as permitted sender) [email protected];
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?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.