On Mon, 13 Apr 2015, sha...@shanew.net wrote:
On Mon, 13 Apr 2015, John Hardin wrote:
On Mon, 13 Apr 2015, Shane Williams wrote:
> Somewhat related questions:
>
> 1. If I alter a rule's score to 0 locally, my understanding is that
> the rule won't even be tested for. Does that also mean it won't count
> toward meta-rules?
That depends on how it's used in the meta rule. If it's used as an
exclusion, setting it to always false won't suppress the meta.
Also: setting the score of a meta to zero won't suppress evaluation of its
component rules.
The specific case I'm wondering about is as part of an arithmetic
expression, like (__RULE1__ + __RULE2__ + RULE3__) > 2.
If I set __RULE2__ to a score of 0, is it now impossible for the meta
rule to trigger (since it can never get more than two "points")?
Strictly speaking, no, because __RULE1__ and __RULE3__ *may* be "tflags
multiple" rules whose individual contributions (hit count) may be > 1.
However, in the simpler case where they are not "tflags multiple" rules,
that is correct.
> 2. Is there a way to create a local rule that uses the DKIM/SPF
> information such that I could match to other headers. In particular,
> I'm looking to either prevent (or at least counteract) the
> "HEADER_FROM_DIFFERENT_DOMAINS" rule when a mailing list is
> involved. So what I'm looking for is a way to test SPF/DKIM against
> the mailing list origination point rather than the sender's. Or
> perhaps I'm missing some smarter way to deal with these situations.
Simple subrules combined in a neta having a negative score. There are
already subrules for detecting mailing list headers and for detecting an
invalid DKIM signature. Write a meta that combines those, and give it
enough negative points to offset the positive score.
Note, however, that mailing list headers are easy for spammers to forge.
What I was getting at (but perhaps not describing well) was finding a
way to compare the mailing list domain with DKIM or SPF in order to
ensure that the mailing list at least arrives from the source we would
expect. It doesn't exactly detect mailing list header forgery, but
could take away a few points for the ones that can be verified. That
said, there me be some reason this totally won't work, so feel free to
tell me so.
Ah, ok. That I missed, or stopped reading too soon. :)
Comparing the domain in two different headers would involve a Header ALL
rule similar to TO_EQ_FM and the like. Those rules might give you a
starting point.
It might be interesting to verify the domain in a list-id header against
some other domain in the headers... (envelope from, perhaps?)
--
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
-----------------------------------------------------------------------
...intellectuals have no interest in what _creates_ wealth, and
what _inhibits_ the creation of wealth. They are very concerned
about the _distribution_ of it, but they act as if wealth just
exists somehow. It's like manna from heaven, it's only a
question of how we split it up. -- Thomas Sowell
-----------------------------------------------------------------------
Today: Thomas Jefferson's 272nd Birthday
