On Thu, Apr 14, 2022 at 2:36 PM Paulo Pinto <paulo.p.azev...@gmail.com> wrote:
> Well, it seems your "logic" has a fatal flaw: direct messages between > accounts on the same domain sent with SMTP auth are not subject to SPF > validation hence they're not SPF authenticated hence your "filter" will > fail and the recipient will be presented with a bogus "this message may be > spam" banner ! > It may be spam. Why do you think it would be impossible for it to be spam? What feature of the message tells us this? Not doing this SPF evaluation won't make our spam handling better. If you're implementing "filters" that shouldn't even exist ( c'mon, SPF > validation during POP retrieval ? Really ? ) at least cover all the > possibilities before creating this type of false positives that really > don't help anyone ( they do the opposite, really ). > They do help a lot of people, actually. The vast majority of email on the internet does not flow between users on a single machine, and the majority of mail that does flow on a single machine doesn't make its way to our servers. And handling "all" the possibilities is never possible, the potential ways in which SMTP is used are innumerable. Our SPF evaluation during POP results in an SPF pass rate only slightly below the rate we see at SMTP time. > Adding fake headers ? That's your suggestion to fix a problem your faulty > "filter" is causing ? > You could DKIM sign the messages, if you feel that would be less ugly. The point is that we can't tell whether or not the sender is spoofing that domain or not, and there are limits to how well the spam filter will work in that situation. Help us help you. > But anyway, and above all: "WHY ?!" > Your interface is being used as a mail client. For that purpose you should > only provide (if you want to, that is ) smtp and pop/imap, period. > Would it be nice for the Outlook mail client start doing SPF/DKIM checks > on POP retrieval too and start flagging all mail from gmail to gmail as > suspicious because there is no SPF check on those ? > There are mail clients and plugins which do that, actually. And gmail to gmail mail will pass this check, and Gmail users do retrieve email from other Gmail accounts with POP, and the check passes. We don't treat gmail to gmail mail as special for this type of spam handling, we know some gmail users send spam, we don't catch it all. Less is more: if your customers want to use your interface as a mail > client, be a mail client. And make our (email providers around the world) > life easier by not creating false positives and panic on our customers. > If people are choosing to use us as their mail client, they are choosing to do so for what we provide, and our spam handling is certainly part of this. POP3 doesn't really provide a mechanism for doing spam marking, so any spam handling for POP3 is going to be on the client side. We've had that SPF check in POP3 fetching for 17 years at this point, it doesn't seem likely to go away. Brandon > This isn't good for you (because we have to say and demonstrate that it is > a gmail bug ) nor for anyone else. > > Cheers. > > On Thu, Apr 14, 2022 at 10:13 PM Brandon Long <bl...@google.com> wrote: > >> Generally speaking, our spam filtering relies strongly on authentication >> signals like SPF & DKIM. >> >> DKIM can of course be evaluated on messages retrieved via POP3, spf is a >> bit more wonky. >> >> What gmail attempts to do is walk the Received header tree looking for a >> Received header that indicates the IP the message was originally received >> on. Obviously, any such header walking has a number of potential failure >> modes, and so the resulting IP may not be the actual IP of the sending >> domain, or it might be entirely internal IP addresses or even just local >> delivery. >> >> The failure mode in that case is that the message is not SPF >> authenticated... which would have been the same result had we not walked >> the headers. >> >> I guess we could just not put any indication in the headers of the >> message that we did that evaluation if it doesn't pass, but it not passing >> is no real indication of anything. >> >> We also do a similar kind of header walking when we accept messages for >> Workspace domains from their inbound gateways. For that, the admin can >> provide a list of internal IP addresses for us to skip... we don't have any >> such provision for POP3. >> >> A better solution would be ARC, where the receiving server could indicate >> what the SPF validation result was on receipt, and we could just validate >> the ARC chain and use that directly. I don't think that would be a high >> priority, however. >> >> When we rolled out the SPF checking for POP3, the rate of false positives >> for spam handling for that mail stream improved significantly. I'm not >> sure if anyone has done a recent evaluation of it. >> >> If your POP3 users are seeing bad spam handling for internal messages, it >> might be useful to add a fake Received header, as ugly as that would be. >> >> Brandon >> >> On Wed, Apr 13, 2022 at 1:08 PM Paulo Pinto via mailop <mailop@mailop.org> >> wrote: >> >>> Hi all. >>> >>> Why on earth is gmail checking the IP address of the message sender (ISP >>> assigned home address, for instance) against the sender's domain SPF >>> without the ability of checking if that original delivery was done using >>> SMTP authentication ( hence voiding the need for that IP being part of the >>> SPF record ) ? >>> >>> Moreover, why on earth is gmail doing a SPF check ( that should ONLY be >>> done during the smtp conversation ) during a pop3 retrieval ?! >>> >>> If there is anyone here from gmail ... fix that please. >>> >>> -- >>> Paulo Azevedo >>> _______________________________________________ >>> mailop mailing list >>> mailop@mailop.org >>> https://list.mailop.org/listinfo/mailop >>> >> > > -- > -- > > Paulo Azevedo >
_______________________________________________ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
