On Thu, 30 Aug 2018, Matus UHLAR - fantomas wrote:
That further causes hitting HDR_ORDER_FTSDMCXX_DIRECT and
HDR_ORDER_FTSDMCXX_NORDNS in cases where client uses the mail client on
local network, without SMTP authentication, and without DNS (which may be
quite common in some organizations).
On 30.08.18 16:57, John Hardin wrote:
Are you experiencing this yourself, so that you can do some testing?
Yes.
If you do have a repro env, can you check whether that internal
network is listed as such in the SA config?
Would you be willing to do this and report whether it hits on those
messages?
header ANY_EXTERNAL_RELAY ALL-EXTERNAL =~ /\S/
score ANY_EXTERNAL_RELAY 0.001
I have tested: ANY_EXTERNAL_RELAY appears when the client's IP is in
trusted_networks, it does not when it's in internal_networks.
Note that I list internal clients as trusted, not as internal.
Maybe this is the problem.
Long time ago I learned to configure dynamic IP addresses (dialups) as
trusted, but not as internal.
In this case, clients are internal, not dialup, but I still think they
should not be listed in internal_networks (as I don't trust them not to
spoof anything).
Filtering on "has an external relay" might be preferable to filtering
on !ALL_TRUSTED since "trust" doesn't say anything about rDNS or it
being a MUA.
note that this problem has been reported on spamassassin-users a month ago:
http://spamassassin.1065346.n5.nabble.com/Problem-with-new-rules-td152105.html
I'd say the problems aren't. That's because the ESP was relaying mail
and not reporting *any* details of the internal handoff, so it looked
to the recipient like the MSA was a mail client.
rDNS wasn't an issue there.
rDNS is not the issue on my side too (it is an issue though).
HDR_ORDER_FTSDMCXX* is the one I'm trying to solve.
--
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.
Atheism is a non-prophet organization.
