Lot of messages, try to recap: There are 2 messages that are not the message I'm "curious" about
1) "Hard" Spoofing: *"Be careful with this message. Our systems couldn't verify that this message was really sent by gmail.com <http://gmail.com/>. You might want to avoid clicking links or replying with personal information."* This result in spam folder and it happens when you replace a char in the from email (e.g: an "o" letter with a "0" zero). The help describe this clearly and tests confirm.. 2) Sender authentication: *"This message may not have been sent by: sender@address"* This seems to happen on SPF failure (even SOFTFAIL) and result in spam folder. Now, the "new" message I'm seeing is instead: 3) "Self-send" Spoofing: *"This may be a spoofed message. Gmail couldn't verify that it was actually sent from your account."* In my tests this *didn't result in spam folder* and it only happened when: 5321/smtp.from: NON-Gmail 5321/smtp.to: Target-Gmail-account 5322/mime.from: Target-Gmail-account 5322/mime.to: Target-Gmail-account (with no dots in local part) SPF: PASS, otherwise you get the error #2 above. DMARC: FAIL (or in other words, a "non-gmail" smtp.from as they correlate) If I send an email from another Gmail account then: 5321/smtp.from: Sender-Gmail-Account (different from the target) 5321/smtp.to: Target-Gmail-account 5322/mime.from: Target-Gmail-account 5322/mime.to: Target-Gmail-account (with no dots in local part) SPF: PASS (I'm sending from gmail) DMARC: PASS (smtp.from is a gmail.com email) Then I get no warnings. I don't understand the reason why this case doesn't show the warning (isn't this a message pretending to be me but not being sent by me like the previous one?). Trying the #3 combination against a GSuite account doesn't show that warning (I get an "?" icon as gravatar and a *tooltip* saying *"My Gsuite name couldn't verify that mygsuitedomain actually sent this message (and not a spammer)"*. This tooltip is there since maybe 1 year, so it is not a "new thing" and also "OT" as I'm focused on the yellow warnings (as almost no one looks at the tooltip of the gravatar). The only explanation I found for introducing a similar message with such a narrow scope is a very conservative path to a larger scope that we'll see in the next weeks/months. Stefano PS: note that if your gmail account is name.surn...@gmail.com then the warning will not appear if you do the "self test" above unless you remove the dot from the localpart of the "rfc5322/mime.to" header (so, you'll see the watning only if To is namesurn...@gmail.com ). But this simply sounds like a bug, not a feature. On 15 June 2017 at 08:08, Stefano Bagnara <mai...@bago.org> wrote: > On 15 June 2017 at 00:37, Laura Atkins <la...@wordtothewise.com> wrote: > >> >> On Jun 14, 2017, at 1:55 PM, Stefano Bagnara <mai...@bago.org> wrote: >> >> Not what I saw here: if I send a message with the same rfc5322.from/to ( >> ema...@gmail.com) to ema...@gmail.com I don't see warnings. >> >> >> I think this is where you’re misunderstanding me. Those are not the same >> email address, therefore, you do not get the warning. ema...@gmail.com and >> ema...@gmail.com are not the same address. So they’re not triggering the >> warning message. >> > > rfc5321.from: mydomain > rfc5321.to: ema...@gmail.com > rfc5322.from: ema...@gmail.com > rfc5322.to: ema...@gmail.com > > This doesn't show the alert when I read it on ema...@gmail.com inbox. So > the message is not only for rfc5322.from + rfc5322.to to be the same, but > ALSO to match your receiving account. > > At this time the only way I see the message is if all of this are the > same, AND DMARC fails: > rfc5321.to: ema...@gmail.com > rfc5322.from: ema...@gmail.com > rfc5322.to: ema...@gmail.com > > Unfortunately (of course) I can't DKIM sign using gmail.com signature, so > we'll never know if they really check DMARC or if they check the received > headers or what technical mean they use to detect the message did not > originate from my account. > > Maybe Brandon will tell us, but it is not really a big point here. > > Let me ask you this, does the warning box have a “learn more” button on >> it? What happens when you click that? Does it take you to a page like: >> https://support.google.com/mail/answer/185812?visit_id >> =1-636330759213411049-1547491413&p=sent_warning&hl=en&rd=2 (that’s the >> page I get from “not sent from your account”) >> >> Note, that support.google.com link provides instructions on how to >> remove the warning. >> > > Brings me here: > https://support.google.com/mail/answer/1366858?hl=en&expand=5 > > Note that "expand=5" seems to not expand anything. > The "Spoofed email address" topic in that page describe a different > behavior (the one that will show the other message I talked about in my > first post, but this is unrelated and IMHO is clearly understandable). > > >> In my sample there are more false positives than spam email matching the >> criteria. But I admit I have a very limited sample. So I trust you when you >> say it is a very common spam technique.. Maybe I already filter those spam >> at SMTP level using spamhaus or that I'm just "lucky" ;-) >> >> >> It’s not a false positive! It’s an accurate statement: this message sent >> to you, from you was not sent through gmail’s servers. It’s simply a >> descriptive message. It’s making sure you notice something about this >> message. Yes, DMARC is showing failed, but DMARC fails when you send from >> addre...@gmail.com to addre...@gmail.com. Those messages don’t get the >> warning. Therefore: the warning is not about a DMARC failure. >> > > Yes, it is accurate. But "This may be a spoofed message." is accurate for > every DMARC failing message. > I meaan "False positive" because in my case the message in fact where NOT > spoofing messages. > > Yeah, they say "MAY BE" so it is accurate. But False positive in spam is > the same.. they put it in spam because it "MAY BE" spam,... so if it is not > spam it is a false positive. > > Particularly in the case of Google, not everything they do is about spam. >> Sometimes they’re just telling subscribers more about the mail. A prime >> example of this - like the TLS indicators. TLS has zero to do with spam. >> Yet, they show the TLS status of every message coming into google. It’s a >> security piece. This, too. >> > > Agree. In my opinion the TLS issue is about much more emails than this > "spoofing" issue. AND the TLS issue is 100% correct, because the message > did some transit in plain text. > > If we want to be "accurate" then EVERY message that fails DMARC PLUS every > message that didn't transit in TLS "may be spoofed" (ignoring what the "To" > header say). > > "rfc5321.to/rfc5322.from/rfc5322.to matching and dmarc failing" (Yes,, I > got thay you think that google detect the origin of the message not > looking DMARC result, but DMARC failing is a correct description in that > case unless you have an use case where the 3 address are the same, DMARC > pass, and the warning is shown anyway). There are many ways to do that > check. > > Stefano >
_______________________________________________ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
