On 30 Aug 2018, at 12:40, Grant Taylor wrote: > On 08/30/2018 10:16 AM, Bill Cole wrote: >> It's hard to understand this circumstance based on the generic description. >> >> It appears that you have a configuration where a relay is in >> trusted_networks (i.e. you believe what it asserts in Received headers) but >> it is NOT in internal_networks so it is in the synthetic >> X-Spam-Relays-External pseudo-header, it is the only element in >> X-Spam-Relays-External so the message matches__DOS_SINGLE_EXT_RELAY, and it >> has no rDNS so the message matches __RDNS_NONE. >> >> So: why is that nameless machine that you cannot make a named machine NOT in >> internal_networks? > > I don't know if this is the OP's case or not, but the following example comes > to mind. > > SA (running on your receiving MTA) receives a message from an MTA (which is > itself an MSA) of an external Business-to-Business partner (thus a trusted > MTA that is not internal to the recipient's organization) which itself > received the message from a client on an RFC 1918 network without reverse DNS.
If that MSA is requiring authentication (as it should) and recording that in the Received header (as it should) then as I understand it, the handoff of the message will not be considered for __RDNS_NONE. >> Of course not, but if a machine is trusted to tell the truth in Received >> headers and has no rDNS because it is talking to a close affiliate on a >> RFC1918 IP, in what sense is it not internal? > > Trusting a B2B partner's external MTA. OK, but in that case the MTA would use an IP that should be in trusted_networks and have rDNS. >> Or is it in internal_networks but there's something wrong in how SA is >> parsing Received headers to build X-Spam-Relays-External? >> >> >> I think the fix for all is for everyone to get their internal_networks and >> trusted_networks configurations correct. > > What should trusted_networks and internal_networks be set to in the B2B > scenario I'm describing? The partner machine's IP should be in trusted_networks AND should have rDNS as an explicit technical requirement of the cooperation, which is entirely reasonable.
signature.asc
Description: OpenPGP digital signature
