Settings not override default actions?

[Frank Schnell]

Trying from the example docs, the symbol gets added, which means this setting is correctly processed.

But greylist happens - it should not. Why?

settings {
test {
priority = high;
rcpt = "user";
symbols [
"TEST_SETTINGS"
]
apply "default" {
actions {
reject = 100;
greylist = 100;
# also tried:
# "soft reject" = 100;
"add header" = 5.0; # Please note the space, NOT an underscore
}
}
}
}

[Andrew Lewis]

Hi,

> Trying from the example docs, the symbol gets added, which means
> this setting is correctly processed.
> But greylist happens - it should not. Why?

Controlling "greylist" action won't control greylisting module.

Actions should not be set to the same threshold as eachother.

If you want to get rid of a default action entirely, define actions {}
in override.d/metrics.conf.

You could then add it back with settings.

To disable greylisting via settings, disable GREYLIST_CHECK and
GREYLIST_SAVE symbols.

https://rspamd.com/doc/modules/greylisting.html

Best,
-AL.

[Frank Schnell]

Hi Andrew, thank you for the response.

>> Trying from the example docs, the symbol gets added, which means
>> this setting is correctly processed.
>> But greylist happens - it should not. Why?
>
> Controlling "greylist" action won't control greylisting module.

That's confusing. If there is no greylist action because the score is too low, why is the greylist module still activated? At least, I hope the team can see that is quite unintuitive for your users and clarification (or funcational change) would be great. In fact, the page you link to states "This module is intended to delay messages that have spam score above greylisting action threshold." I changed the threshold so expect the greylisting to be bypassed. Presently, I don't know under what circumstances greylisting is actually triggered or not. Is it matter of order of execution? If so, I suggest a documentation page to more clearly explain the architecture.

> Actions should not be set to the same threshold as eachother.

Changing them didn't have any effect on this problem.

> If you want to get rid of a default action entirely, define actions {}
> in override.d/metrics.conf.
>
> You could then add it back with settings.

I prefer to have a default setup with per-user overrides for some things. Disabling the symbols you mentioned does not work:

apply "default" {
GREYLIST_CHECK = 0;
GREYLIST_SAVE = 0;
actions {
reject = 100;
greylist = 99;
"add header" = 5; # Please note the space, NOT an underscore
}
}

Is that not your meaning "disable those symbols"?

[Andrew Lewis]

Hi,

> That's confusing. If there is no greylist action because the score
> is too low, why is the greylist module still activated?

It only cares that action is _not_ 'reject' or 'no action' - the
significance of 'greylist' action is mostly lost in time (it means
something like Rmilter should perform greylisting which doesn't make
sense anymore).

> Is that not your meaning "disable those symbols"?

No, zeroing score for a symbol doesn't disable it. `symbols_disabled`
in 'settings' disables symbols.

Best,
-AL.

[Frank Schnell]

Andrew, your help is appreciated.

>> Is that not your meaning "disable those symbols"?
>
> No, zeroing score for a symbol doesn't disable it. `symbols_disabled`
> in 'settings' disables symbols.

My fault, this was in the documentation and I overlooked it. However, it still greylists even having disabled those symbols. In the log for the soft-rejected mail I see a symbol "GREYLIST" with "new record" indicated. Should I disable the "GREYLIST" symbol?

settings {
testing {

priority = high;
rcpt = "user";
symbols [

"TEST_SYMBOL"
]
apply "default" {
actions {
symbols_disabled = ["GREYLIST_CHECK", "GREYLIST_SAVE"];

reject = 100;
greylist = 99;

"add header" = 5.0; # Please note the space, NOT an underscore
}
}
}
}

Here is also local.d/metrics.conf
actions {
reject = 20;
add_header = 5;
greylist = 4;
};

[Frank Schnell]

update: adding "GREYLIST" to the disabled symbols has no effect, message is still soft-rejected

> --
> You received this message because you are subscribed to the Google Groups "rspamd" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to rspamd+un...@googlegroups.com.
> Visit this group at https://groups.google.com/group/rspamd.

[Vsevolod Stakhov]

On 06/10/17 18:04, Frank Schnell wrote:
> Andrew, your help is appreciated.
>
>>> Is that not your meaning "disable those symbols"?
>>
>> No, zeroing score for a symbol doesn't disable it. `symbols_disabled`
>> in 'settings' disables symbols.
>
> My fault, this was in the documentation and I overlooked it. However, it still greylists even having disabled those symbols. In the log for the soft-rejected mail I see a symbol "GREYLIST" with "new record" indicated. Should I disable the "GREYLIST" symbol?
>
> settings {
> testing {
> priority = high;
> rcpt = "user";
> symbols [
> "TEST_SYMBOL"
> ]
> apply "default" {
> actions {
> symbols_disabled = ["GREYLIST_CHECK", "GREYLIST_SAVE"];

Why is it in actions? That will not work at all. Please read the
settings docs more carefully...

[Frank Schnell]

Vsevolod, thank you for spotting the mistake.

[Frank Schnell]

Thanks to Vsevolod and Andrew for explaining that overriding greylist action in settings module is tricky, but it works well when pieced together.

Now I tried to change the "add header" threshold, but it didn't seem to have any effect. Is there also more complicated configuration required to do this? I tried this and expect to have X-Spam header for messages to "user" with score over 1, but only the default add header scoring from local.d/metrics.conf is applied and action for message with score around 2 is "no action".

settings {
testing {
priority = high;
rcpt = "user";
symbols ["TEST_SYMBOL"];
apply "default" {
actions {

reject = 100;
"add header" = 1.0; # Please note the space, NOT an underscore
}
}
}
}

I confirmed that this setting is being matched and applied with "TEST_SYMBOL" in logs.

[Andrew Lewis]

Hi,

> apply "default" {
> actions {
> reject = 100;
> "add header" = 1.0; # Please note the space, NOT an underscore
> }
> }

Actions should have some particular scores relative to eachother.
Given actions scored as per the default config, you would need to
rescore `greylist` action too to be < `add header` in this case. Maybe
you should just be adding headers when you want them via milter
headers module however.

`no action` should conventionally be set at 0. no action < greylist <
add header < rewrite subject < reject.

Best,
-AL.

[Andrew Lewis]

Hi,

> `no action` should conventionally be set at 0.

Sorry, that's misleading. In fact the threshold for `no action` is
effectively higher (it is everything < greylist). Rather what I try to
say that negative scores are by convention considered innocent, so
thresholds for actions should be positive.

Best,
-AL.

[Frank Schnell]

Thank you. Your response didn't emphasize the problem, so for others: if you want to change the scoring thresholds in the settings module, you must provide a threshold score for every action that is in the default setup (or whatever you have in local.d/metrics.conf). And the hierarchy should never be out of order as you discuss.

The settings module documentation might benefit from clarification of this important rule.

[Frank Schnell]

Thanks to Vsevolod and Andrew for pointing out the finer details of changing rspam behavior using settings module. I have tested to show it works good.

When move same configuration to HTTP service, Rspamd acts unpredictably. Same configuration of threshold override sometimes loads and process correctly, sometime thresholds are ignored. I can't find what is the cause after many experiments changing thresholds (but always keep them in order/relative) and reloading rspamd.

I can see when custom threshold scoring is working because I see my reject threshold in log:
default: F (no action): [1.05/7.00]
Then after test change *only* the thresholds (and reload), its ignored, I see default reject threshold:
default: F (no action): [2.85/15.00]
I change back to the custom threshold scoring that worked above (and reload), but still ignored!

Confirmed loaded settings after reload:
#27201(controller) <4ud1gp>; lua; settings.lua:533: loaded 2 elements of settings
Also tried full rspamd restart, doesn't help

rspamadm configdump cannot help because it only shows URL of HTTP service. Is there another way to see parsed config loaded from HTTP service?

I saw this once before when using /etc/rspamd/rspamd.conf.local but I thought it was a configuration mistake, now I think rspamd workers or something is acting strange

Example of HTTP service content:

test_setting {

priority = high;
rcpt = "user";
symbols [

"TEST_SETTING"
]
apply "default" {
actions {
reject = 7.00;
"add header" = 5.00;
greylist = 3.00;
}
}
}

[Andrew Lewis]

Hi,

> I can see when custom threshold scoring is working because I see my
> reject threshold in log:
> default: F (no action): [1.05/7.00]
> Then after test change *only* the thresholds (and reload), its
> ignored, I see default reject threshold:
> default: F (no action): [2.85/15.00]
> I change back to the custom threshold scoring that worked above (and
> reload), but still ignored!

I can't replicate that. Maybe you have some other settings that are applied.

> Confirmed loaded settings after reload:
> #27201(controller) <4ud1gp>; lua; settings.lua:533: loaded 2
> elements of settings

Suggests you have > 1 set of settings but you've only showed one.

Logs will tell which settings are applied.

Best,
-AL.

[Frank Schnell]

> Hi,
>
>> I can see when custom threshold scoring is working because I see my
>> reject threshold in log:
>> default: F (no action): [1.05/7.00]
>> Then after test change *only* the thresholds (and reload), its
>> ignored, I see default reject threshold:
>> default: F (no action): [2.85/15.00]
>> I change back to the custom threshold scoring that worked above (and
>> reload), but still ignored!
>
> I can't replicate that. Maybe you have some other settings that are applied.

I see over time it appears to settle into the correct settings. I reproduced it now by issuing a manual reload of the service. Thresholds go back to default level for some time.

> Logs will tell which settings are applied.

Yes, like this:
lua; settings.lua:293: <*msgid*> apply settings according to rule test_setting

After reload, there is no "apply settings" applied to the same test email that triggers the test setting. I don't know how long it takes until it starts working again. Also confirmed settings were retrieved when reload happened again, so the settings are there but rspamd not using them:
lua; settings.lua:533: loaded 3 elements of settings