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?
multiple client PCs in the local network.
and as client PCs, I don't want to put them into internal_networks.
(And if I remember correctly, I should not).
On 30 Aug 2018, at 12:40, Grant Taylor wrote:
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.
On 30.08.18 15:08, Bill Cole wrote:
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.
Authentication not implemented yet, and telling the network admins they must
to implement it now that I have installed spamassassin, is not acceptable.
Tuning DNS is of course possible but it requires some time.
--
Matus UHLAR - fantomas, [email protected] ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
I wonder how much deeper the ocean would be without sponges.
