On Fri, 31 Aug 2018, Matus UHLAR - fantomas wrote:
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.
Thanks!
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.
It shouldn't have anything to do with trusted_networks, it's intended to
check whether or not all the participating IPs are in internal_networks.
There's currently no rule for doing that.
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.
Hrm. Not sure which way to go in that case. Dialup IPs (unless statically
assigned to a specific user account) are not really a reliable indicator
of internal or trusted... Any of that ISP's clients could get that IP and
suddenly be able to get preferential treatment by your mail system.
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).
Trusting to not spoof headers is what the trusted_networks list is for.
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.
Well, that's basically a just check for MSFT MUAs, and spam
tools that slavishly mimic the headers such clients produce...
--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
[email protected] FALaholic #11174 pgpk -a [email protected]
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
Riff: Torg, you traded our magic beans for a _cow_?
Torg: It's a _magic_ cow! It's full of steaks!
Riff: Whoa! -- Sluggy 04/28/2002
-----------------------------------------------------------------------
519 days since the first commercial re-flight of an orbital booster (SpaceX)
