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 <[email protected]> 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 > [email protected] > https://list.mailop.org/listinfo/mailop >
_______________________________________________ mailop mailing list [email protected] https://list.mailop.org/listinfo/mailop
