On Fri, 31 Aug 2018, John Hardin wrote:
None of the masscheck corpora that hit __HDR_ORDER_FTSDMCXXXX also
hit ALL_TRUSTED (or at least the portion is so small it falls off
the bottom of the report) so I don't feel too worried about adding
either !ALL_TRUSTED or __ANY_EXTERNAL (or potentially both) as
exclusions.
I'm adding __ANY_EXTERNAL now...
Comments solicited.
On Fri, 31 Aug 2018 16:16:43 -0700 (PDT) John Hardin wrote:
Here's one: should __ANY_EXTERNAL be added to any other rules that
primarily look for abused MSFT-isms?
For example, MIMEOLE_DIRECT_TO_MX, DOS_OE_TO_MX, DOS_OUTLOOK_TO_MX,
XPRIO_SHORT_SUBJ, ...?
On Sat, 1 Sep 2018, RW wrote:
All but the last one is a direct-to-mx rule, which requires one
external relay, so adding __ANY_EXTERNAL to those is pointless.
On 01.09.18 18:57, John Hardin wrote:
Ugh, you're right. I didn't reread the rule details before posting
that suggestion - sorry, I've been a little distracted by plumbing
issues this week. :)
__ANY_EXTERNAL on HDR_ORDER_FTSDMCXX_DIRECT is also pointless because
it uses __DOS_SINGLE_EXT_RELAY, which is "exactly one external IP
present." Same for HDR_ORDER_FTSDMCXX_NORDNS with __RDNS_NONE. Taking
__ANY_EXTERNAL back off of those. Same excuse. :)
!ALL_TRUSTED will be masscheck-neutral and will help in the situation
you describe, so I'll add it; the only failure mode I can see there is
if you add an external ESP to your trusted networks and they discard
internal and submission details so that they look like a MUA, and then
one of their clients sends spam that would otherwise hit the rule. Is
an ESP doing that considered "forging headers" sufficiently to *not*
earn trust? Or does simply *discarding* headers not cross that line?
I believe that discarding Received: headers DOES cross the line.
As long as the point of trusted_hosts is to skip checking for them in
blacklists BUT checking hosts behind instead, clearing Received: headers
causes sabotaging the trust here.
removing/not adding those headers in fact means forging them
I don't think __ANY_EXTERNAL is a good idea, it should be sufficient
that the headers are all trusted
Trusted and Internal are different things. I think it's a bad idea to
conflate them or treat them as equivalent and interchangeable.
I think __ANY_EXTERNAL is still weakly needed. There's a rule for
exactly one external IP (__DOS_SINGLE_EXT_RELAY) and there's a rule
for multiple external IPs (__DOS_RELAYED_EXT) but there's nothing for
"are there *any* external relays?" __DOS_SINGLE_EXT_RELAY ||
__DOS_RELAYED_EXT would be equivalent but I feel it should be more
direct than that for clarity, unless we have performance concerns with
another RE vs. a meta, which is unlikely.
I believe that for the rules in account, __DOS_SINGLE_EXT_RELAY is just fine
- in my case (I am the OP) we are handling mail that came directly from
trusted but external hosts.
__ANY_EXTERNAL requires that people read this thread and make a
questionable change to their networks to take advantage.
I don't think so. The documentation seems to be quite clear in what should
and what should not be put into trusted_networks and internal_networks.
Actually listing in internal_networks IPs considered "internal to the
organization" is questionable?
If there's some issue with listing public dialup (presumably dynamic)
IPs used by members of the organization in internal_networks,
not internal_networks, only in trusted_networks. Just as documented in
https://wiki.apache.org/spamassassin/DynablockIssues
then
maybe we need another way to specify "these IPs are considered
internal for submission purposes even though they don't authenticate".
This could help much, but it also means much work with SA changes.
For now, I believe that using (ALL_TRUSTED && __DOS_SINGLE_EXT_RELAY)
is just what I need to prevent all rules from firing:
HDR_ORDER_FTSDMCXX_001C
HDR_ORDER_FTSDMCXX_BAT
HDR_ORDER_FTSDMCXX_DIRECT
HDR_ORDER_FTSDMCXX_NORDNS
... as long as some mentioned above:
DOS_HIGH_BAT_TO_MX
DOS_OE_TO_MX
DOS_OE_TO_MX_IMAGE
DOS_OUTLOOK_TO_MX
MIMEOLE_DIRECT_TO_MX
Further thinking about trusted_networks and relaying mail, I think that
the difference between remote server and local trusted client, when both are
listed in trusted_networks, is that mail from remote server contains more
than one Received: header, while local trusted client only one.
In this case, trusted server removing or not providing any Received: lines
would be understood as client, avoiding hitting rules above.
OTOH, trusted clients providing fake headers are something that could cause
troubles by hitting whitelist -firsttrusted rules.
This is the only problem I can see coming from trusting local clients - but
since they must be trusted to avoid local blacklist, I see no way to avoid
this than change to SA trust path (drop all Received: after this hosts).
comments welcome.
--
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.
- Holmes, what kind of school did you study to be a detective?
- Elementary, Watson. -- Daffy Duck & Porky Pig
