[Rspamd-Users] Best way to kill a rule

[Vsevolod Stakhov]

On 25/09/2019 16:11, Vadim Zeitlin wrote:
> On Wed, 25 Sep 2019 15:56:46 +0100 Vsevolod Stakhov <vsevolod at rspamd.com> wrote:
> 
> VS> On 25/09/2019 11:48, Sophie Loewenthal wrote:
> VS> > Hi,
> VS> > 
> VS> > Would this be a good way to render a rule impotent?  I don’t think so. Is there a preferred way?
> VS> > 
> VS> > 
> VS> > # cat local.d/settings.conf
> VS> > kill_virusfree_rule {
> VS> >   priority = high;
> VS> >   from = "/@.+\..+/";
> VS> >   apply {
> VS> >         RBL_VIRUSFREE_BOTNET = 0.0;
> VS> >   }
> VS> > }
> VS> > 
> VS> > Best wishes, 
> VS> > S
> VS> > 
> VS> 
> VS> Please read the FAQ document before asking questions in the mailing list.
> 
>  Notwithstanding this excellent advice, I feel that the FAQ answer to the
> "How can I disable some Rspamd rules safely" question could be somewhat
> improved: first, it would be great to have a concrete example. Second, it
> mentions several ways of disabling a rule, but doesn't say what are the
> advantages and drawbacks of each of them and it's not really clear which
> one to choose (it does say that the first one is "easiest", but it doesn't
> really seem to be easier than using "enabled = false" or "symbols_disabled"
> to me).
> 
>  Unfortunately, I don't know the answers to these questions myself, so I
> can't contribute a fix, but I just wanted to mention that it could well be
> worth improving this section of the FAQ.
> 
>  Regards,
> VZ
> 
> 

There are two types of symbols disabling:

* Static - done via configuration and prevents symbols from being registered
* Dynamic - determined on each scan

When you disable a module via `enabled = false` it statically disables
all symbols that are registered from this module. This is the most
efficient way in terms of performance.

Some modules, in particular RBL module, allows to turn off some rules by
setting them to null in `local.d/rbl.conf` as following:

virusfree = null;

However, that's not a general case.

Dynamic symbols management is more expensive. When you add a condition
to some symbol, Rspamd needs to call Lua function. It is cheap but not free.

>From version 2.0, settings that merely define symbols or groups
inclusion/exclusion lists are also quite cheap. In 1.9 branch it is a
more expensive operation (similar to dynamic settings header in 2.0+).
However, I do not recommend to use settings for some 'default' setup: it
is confusing and might lead to very complicated bugs.

Another thing that should be considered is that in 2.0 settings can
disable virtual symbols whilst in 1.9 they disabled the whole rule. To
explain this, I need to tell that there are rules and symbols and they
are NOT the same things.

* A rule is a piece of code that is executed by Rspamd.
* A symbol is an outcome of rule's execution, however, a single rule can
insert more than one symbol. Vice versa, a single symbol can be inserted
from multiple rules.

Currently, all rules are identified by so called 'callback' symbols:
they have their name but they are never ever inserted to the results.
For example, `DKIM_CHECK`. All other DKIM outcomes, e.g. `DKIM_ALLOW` or
`DKIM_REJECT` are virtual symbols that are linked with their parent
`DKIM_CHECK`. In 1.9, if you disable `DKIM_REJECT` via settings then the
whole `DKIM_CHECK` is disabled as well. In 2.0, this will cause
`DKIM_CHECK` to be executed but `DKIM_REJECT` cannot be inserted
(though, it does NOT disable `DKIM_ALLOW` and others).

Conditions works for rules, so adding a condition to `DKIM_ALLOW`
implies a condition to the whole `DKIM_CHECK` rule and all symbols it
can insert (in fact, it will not be executed at all).

Furthermore, if you have more that 4 settings id it can be more
expensive in some cases, so I'd not recommend to have lots of static
settings unless absolutely required.

To summarise, the FAQ section clearly describes the most generic and the
most efficient way to do dynamic symbols disabling. Settings usage is
appropriate if you want to have different scanning behaviour depending
on some conditions but not just for altering the default behaviour.

Static disabling is more effective but it is not generic and thus is not
recommended unless you clearly understand what are you doing.