[Rspamd-Users] Best way to kill a rule

[Sophie Loewenthal]

> On 25 Sep 2019, at 17:37, Vsevolod Stakhov <vsevolod at rspamd.com> wrote:
> 
> 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.
> — 
> 


Thank-you for describing this in such detail.  This gives me a better understanding and appreciation. I had read the FAQ before I posted.