On 3/25/19 7:01 PM, Henrik K wrote:
On Mon, Mar 25, 2019 at 06:49:49PM +0100, Tobi <jahli...@gmx.ch> wrote:
Am 25.03.19 um 15:18 schrieb Henrik K:
On Mon, Mar 25, 2019 at 03:00:30PM +0100, Tobi <jahli...@gmx.ch> wrote:
You are matching "any uri" and expect it to be "reliable"? Perhaps consider
first what you are trying to accomplish. Your way will match mailto: and
strings like perl.pl etc, but perhaps that's fine.
to account for mailto hits we use another rule like
uri __HAS_URI_AT /\@/
in our case we do not care if we hit perl.pl as domain in the body. In
that case the meta rule using the two __HAS rules just won't fire, which
is okay.
The meta tries to hit on that crappy "are you in the office ? Can we
transfers XXXXX EUR today"-spearphishes. Which as far as we can see
never contain a URI in body of the message (at least in our spamflow).
But now we got a case which slipped through although the criterias for
the meta to fire were given. But as they used dkim for their crap
spamassassin finds a URI in d= of the header and our meta does not fire
anymore.
So I hoped that "parse_dkim_uris = 0" would solve this but at least in
our 3.4.2 setup this config has no effect on the hit of the URI in the
dkim header
You could try something nasty like
uri __HAS_URI /./
tflags __HAS_URI multiple
meta __REALLY_HAS_URI (DKIM_SIGNED && __HAS_URI > 1) || (!DKIM_SIGNED &&
__HAS_URI)
seems to me everybody is making an effort in disregarding the fact that
the URI rule was hitting on a header and imo, that should not happen.
This makes the whole uri behaviour even more unpredictable.
