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.
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.
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?
-- Grant. . . . unix || die
smime.p7s
Description: S/MIME Cryptographic Signature
