Rspamd directives in check_message.conf not processed

NextIT

Verified User
Joined
May 30, 2004
Messages
15
Location
Netherlands
I successfully configured rspamd using the instructions on this forum and in the readme.txt. Rspamd is adding its headers and seems to be running fine. However, I noticed that greylisting was not working (even after configuring redis) and also that the other in directives in "/etc/exim/rspamd/check_message.conf" didn't seem to be processed.

Although I am not an exim expert, I think i identified the issue...

At the start of an SMTP connection "/etc/exim/rspamd/connect.conf" sets the "acl_m_rspamd" variable to 1. This can be observed in the Exim debug log when a new SMTP session starts:

Code:
Aug 25 17:47:52 test exim[17178]: 17653 processing "warn"
Aug 25 17:47:52 test exim[17178]: 17653 check set acl_m_easy69 = 0
Aug 25 17:47:52 test exim[17178]: 17653 check set acl_m_esf_skip = 0
Aug 25 17:47:52 test exim[17178]: 17653 check set acl_m_rspamd = 0
Aug 25 17:47:52 test exim[17178]: 17653 warn: condition test succeeded in ACL "acl_connect"
Aug 25 17:47:52 test exim[17178]: 17653 processing "warn"
Aug 25 17:47:52 test exim[17178]: 17653 check set acl_m_rspamd = 1
Aug 25 17:47:52 test exim[17178]: 17653 warn: condition test succeeded in ACL "acl_connect"
Aug 25 17:47:52 test exim[17178]: 17653 processing "accept"
Aug 25 17:47:52 test exim[17178]: 17653 check hosts = *
Aug 25 17:47:52 test exim[17178]: 17653 host in "*"? yes (matched "*")
Aug 25 17:47:52 test exim[17178]: 17653 accept: condition test succeeded in ACL "acl_connect"
Aug 25 17:47:52 test exim[17178]: 17653 end of ACL "acl_connect": ACCEPT
Aug 25 17:47:52 test exim[17178]: 17653 SMTP>> 220 test.nextit.nl ESMTP Exim 4.91 Sat, 25 Aug 2018 17:47:52 +0200

As can be seen, this all happens before the EHLO. The exim documentation on ACL variables mentions:

The values of those variables whose names begin with $acl_m persist only while a message is being received. They are reset afterwards. They are also reset by MAIL, RSET, EHLO, HELO, and after starting up a TLS session.

This would mean that the variable is reset after the HELO because the acl_m_rspamd variable starts with an 'm_'. The 'on/off' switch in the check_message.conf file checks for this variable in order to activate the various directives in the config:

Code:
# General on/off switch.
	warn	logwrite = acl_m_rspamd:$acl_m_rspamd
	warn 	condition = ${if eq{$acl_m_rspamd}{1}}
			condition = ${if !eq{$acl_m_esf_skip}{1}}
			condition = ${if < {$message_size}{EASY_SPAMASSASSIN_MAX_SIZE}}
			condition = ${if !eq{$acl_m_spam_user}{nobody}}
			set acl_m_rspamd_on = 1

This "eq{$acl_m_rspamd}{1}" always fails because the variable was reset after the EHLO:

Code:
Aug 25 17:47:52 test exim[17178]: 17653 processing "warn"
Aug 25 17:47:52 test exim[17178]: 17653 check condition = ${if eq{$acl_m_rspamd}{1}}
Aug 25 17:47:52 test exim[17178]: 17653                 =
Aug 25 17:47:52 test exim[17178]: 17653 warn: condition test failed in ACL "acl_check_message"

I implemented a simple workaround by adding the following directive to the check_messages.conf file:

Code:
warn	set acl_m_rspamd = 1

Is this a bug or am I missing something else?
 
It's basically a change to the check_message.conf:
I don't see how this will fix the issue. You removed the line that sets acl_m_rspamd_on to 1, but all the other statements in check_message.conf still have a condition that check for this variable to be set:

Code:
condition = ${if eq{$acl_m_rspamd_on}{1}}

These will never evaluate to true and the statements won't be executed, right?
 
No, I removed the setting that sets it to 0 in the check_message.conf.
The connect.conf is where it's set to 1.

Basically, the check_message.conf should not set the variable anywhere, hence we removed it.
The conditions check for 1, which will be true because the connect.conf set it that way.

Let me know if I'm missing something :)

John
 
Let me know if I'm missing something :)
I see that connect.conf sets the variable 'acl_m_rspamd', but check_message.conf is using 'acl_m_rspamd_on'. I would think that this is not the same variable, or does the '_on' suffix has some kind of special meaning in the exim configuration syntax?
 
Ah thanks for that. The _on is what I was missing :)

I guess the main concern is to try and sort out why setting it through the connect.conf isn't sticking?
I couldn't find any documentation that would show the variable getting reset back to 0.

In that case, 0.1 should have worked correctly, so it was probably just skipping for some reason.
I've flipped 0.2 around again and added extra logging to explain why it was skipped, providing all of the "OR" conditions that could have caused it.

warn condition = ${if eq{$acl_m_rspamd}{1}}
# General on/off switch.
warn set acl_m_rspamd_on = 0
warn condition = ${if eq{$acl_m_rspamd}{1}}
condition = ${if !eq{$acl_m_esf_skip}{1}}
condition = ${if < {$message_size}{EASY_SPAMASSASSIN_MAX_SIZE}}
condition = ${if !eq{$acl_m_spam_user}{nobody}}
set acl_m_rspamd_on = 1
warn condition = ${if eq{$acl_m_rspamd}{1}}
condition = ${if eq{$acl_m_rspamd_on}{0}}
logwrite = Rspamd should be on but was skipped for some reason: acl_m_esf_skip=$acl_m_esf_skip OR (message_size=$message_size) >= EASY_SPAMASSASSIN_MAX_SIZE OR (acl_m_spam_user=$acl_m_spam_user)==nobody
# scan the message with rspamd
Anyway, give that a try. It's likely being skipped.
I know the acl_m_esf_skip can happen for various reasons, so that might have been the original confusion.

In any case, I've given the change a thorough test on a live test box, and is working.
Note, if you see this in your exim mainlog:
Code:
018-09-15 18:37:27 1.2.3.4 whitelisted in list.dnswl.org
this accepts the message, thus it might not be scanned at all, and rspamd never even stars, since it was already accepted.
If that's confusing, just comment out the entire #EDIT#35: section of your exim.conf so the messages goes through all the hoops :)

In any case, my manual test added these headers to the message, so does appear to be working (ignore the fact that my manually created email is missing many headers):
Code:
X-Spam-Score: 7.3 (+++++++)X-Spam-Report: Action: add header
 Symbol: ARC_NA(0.00)
 Symbol: MISSING_FROM(2.00)
 Symbol: R_SPF_ALLOW(-0.20)
 Symbol: MISSING_DATE(1.00)
 Symbol: MIME_GOOD(-0.10)
 Symbol: DMARC_NA(0.00)
 Symbol: MISSING_MID(2.50)
 Symbol: RCVD_IN_DNSWL_MED(0.00)
 Symbol: MISSING_TO(2.00)
 Symbol: RCVD_COUNT_ONE(0.00)
 Symbol: RCVD_NO_TLS_LAST(0.00)
 Symbol: R_DKIM_NA(0.00)
 Symbol: ASN(0.00)
 Symbol: FROM_NEQ_ENVFROM(0.00)
 Symbol: ONCE_RECEIVED(0.10)
 Message: (SPF): spf allow
 Message-ID: undef
SpamTally: Final spam score: 33

John
 
I guess the main concern is to try and sort out why setting it through the connect.conf isn't sticking?
I think I already sorted that out. :) Let me explain. As I wrote in my original post, the variable is set before the EHLO. The exim documentation on ACL variables mentions:

The values of those variables whose names begin with $acl_m persist only while a message is being received. They are reset afterwards. They are also reset by MAIL, RSET, EHLO, HELO, and after starting up a TLS session.

This means the variable is set when a connection starts, but is reset again before the spam processing takes place (after the EHLO and DATA commands). It also explains:

- The values of those variables whose names begin with $acl_c persist throughout an SMTP connection. They are never reset. Thus, a value that is set while receiving one message is still available when receiving the next message on the same SMTP connection.

- The values of those variables whose names begin with $acl_m persist only while a message is being received. They are reset afterwards. They are also reset by MAIL, RSET, EHLO, HELO, and after starting up a TLS session.

Considering this, the solution would be simple: rename acl_m_rspamd to acl_c_rspamd.
 
Back
Top