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)
