On Sat, 1 Sep 2018, RW wrote:
On Fri, 31 Aug 2018 16:16:43 -0700 (PDT)
John Hardin wrote:
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.
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, ...?
All but the last one is a direct-to-mx rule, which requires one
external relay, so adding __ANY_EXTERNAL to those is pointless.
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'm curious why you have
header ANY_EXTERNAL_RELAY ALL-EXTERNAL =~ /\S/
which looks for an external header rather than the more straightforward
header ANY_EXTERNAL_RELAY X-Spam-Relays-External =~ /\S/
which looks for an external relay. I think they are functionally
equivalent.
You're right, they should be equivalent. The former is a little shorter.
The latter is what I actually checked into SVN, for consistency with (most
of) the other "external" rules.
I don't know that one is more "straightforward" than the other.
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.
__ANY_EXTERNAL requires that people read this thread and make a
questionable change to their networks to take advantage.
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, then maybe we
need another way to specify "these IPs are considered internal for
submission purposes even though they don't authenticate".
--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhar...@impsec.org FALaholic #11174 pgpk -a jhar...@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
Should you meet with a person bent on a campaign of terror,
intending to murder their fellow men and women, to leave behind a
swath of widows, widowers and orphans, to grieve families and
nations alike, do the reasonable thing. Kill them.
-- Matthew @ StraightForward
-----------------------------------------------------------------------
520 days since the first commercial re-flight of an orbital booster (SpaceX)
