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 !
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 ). Adding fake headers ? That's your suggestion to fix a problem your faulty "filter" is causing ? 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 ? 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. 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 <[email protected]> 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 <[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 >> > -- -- Paulo Azevedo
_______________________________________________ mailop mailing list [email protected] https://list.mailop.org/listinfo/mailop
