On Tue, 23 Feb 2021 13:41:58 -0800 (PST) John Hardin wrote: > On Tue, 23 Feb 2021, Dan Malm wrote: > > > On 2021-02-23 16:29, John Hardin wrote: > >> On Tue, 23 Feb 2021, Dan Malm wrote:
> >>> Received: from onecom-webmail1 (service.pub.appspod1-cph3.one.com > >>> [ ]) > >>> by mailrelay3 (Halon) with > >>> id 89da92dc-72a5-11eb-bf40-fd1a731c465d; > >>> Fri, 19 Feb 2021 11:28:08 +0000 (UTC) > >>> X-Originating-IP: 46.30.211.29 > > And "X-Originating-IP: 46.30.211.29" is the IP the webserver > > handling the webmail saw for this mail, i.e. the user IP, which for > > normal users will often be in PBL. It's also the IP that triggers > > the hit on RDNS_NONE > > Which it should not, as it's not the "last external" IP address. > That's why I asked for the headers - it seems from this (absent any > actual testing) that SA isn't keeping the received-equivalent headers > in the correct order with the genuine received headers. I've explained this in a recent post in this thread. Without the SMTPA you would have X-Spam-Relays-External: [ ip=46.30.211.130 ...][ ip=46.30.211.29 ...] With authentication (SMTPA) the networks move down one and you get X-Spam-Relays-Internal: [ ip=46.30.211.130 ...] X-Spam-Relays-External: [ ip=46.30.211.29 ...] In most cases doing this leave X-Spam-Relays-External empty and it prevents running LE tests on mail submission, but it takes no account of sections added for Originating-IP or upstream Received headers. This behaviour is actually abusable as a forged header can be used trigger various whitelisting rules, see Bug 7590.
