On 30 Aug 2018, at 10:01, Matus UHLAR - fantomas wrote:
On 30.08.18 09:49, Kevin A. McGrail wrote:
I feel that you are fighting a bigger battle than one rule in SA.
two rules actually ;-) (with two more possible).
Without RDNS, you are running afoul of the postmaster rules of
virtually
every major email player. You will have massive deliverability
issues..
Those IP addresses are in internal network with private IP ranges.
When
connecting to world, their IPs are NAtted to public.
even if I fixed the DNS (and I can't since the network is not in my
control), HDR_ORDER_FTSDMCXX_DIRECT would still apply.
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 believe faking DNS is not what you advise to me, although it would
"fix"
the problem temporarily (but could create another problem should the
DNS be
created later).
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?
Or is it in internal_networks but there's something wrong in how SA is
parsing Received headers to build X-Spam-Relays-External?
That is why I believe that adding ALL_TRUSTED would solve the problem
without unnecessary issues for others.
Yes, I can do that locally - but by redefining rule I could miss it
getting
fixes or improved later.
And since different people have already reportted this problem in the
past,
I would like to make the fix possible for all, if viable.
I think the fix for all is for everyone to get their internal_networks
and trusted_networks configurations correct.
