Sorry, I was on vacation last week. This new warning was added because Gmail is something of a special case. Right now, the "Sent Mail" label is essentially just a special filter on from:me, which is very different from most mail clients. In most mail clients, the sent folder is only mail that was actually sent or was manually moved there by the owner, there's no way for someone to get their message in your sent folder. In Gmail, that's not true.
We don't just spam folder that case, however, because several things take advantage of this fact on purpose, to make mail end up in the sent mail label that was say sent with some other tool. In fact, that's generally how this Email Compliance rule works ( https://support.google.com/a/answer/3547347) for the sender (well, that's a simplification, but you get the idea). So, the warning is there so people aren't confused if a message they never sent is in their sent mail label. It's kind of a stop-gap, theoretically we could do a major overhaul to change how the sent mail label works and try and catch all of these other cases or store some other piece of information to make it obvious to the user what they sent and what they didn't. As such things go, I imagine it's lifetime will be much longer than one would hope for. Because it's a spam rule, I imagine there are a bunch of caveats applied to try and separate good cases from bad, but that's the overall reason for the rule. The Gmail spam team would still love to turn on p=quarantine or reject for gmail.com, or even switch to "no auth no entry", but they can't really do that until the false positives are low enough, and they're not there yet. ARC may be enough, it may not be. Obviously, measuring the false positive rate as it impacts other receivers is also challenging, the dmarc aggregate reports only help so much (they'll tell you how many are blocked, not how many are messages the user wants to receive). Brandon On Thu, Jun 15, 2017 at 1:40 AM, Stefano Bagnara <mai...@bago.org> wrote: > 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 > >
_______________________________________________ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
