problem with spam_status #849
Comments
|
The log don't show any "abnormal" behaviour. No blocking, no error, no warning except "normal" ones (bad formed mail, some config file with little warning, etc.) even with loglevel 4 (If I put 5, journald is overflowed...) |
|
|
it seems that do_match function is never called, but only this string |
|
When I tried } elsif ($condition_key eq 'match') {
return sprintf 'Sympa::Scenario::do_match($that, $context, %s)',join ', ', @args;
##########
return sprintf '(%s =~ %s)', $args[0], $args[1];
}I have |
Merged
|
Hi @fprigent , |
|
Hi @ikedas |
|
|
when I add return sprintf 'Sympa::Scenario::do_%s($that, \'%s\', %s)',
$condition_key, $condition_key, join ', ', @args;I have this: |
|
I'm verifying my scenarios... With my tests, I may have broke something. |
|
I tried with these lines spam-status scenario (to have every case for subject) I have |
|
@fprigent , please minimize content of scenario: Remove lines one by one to get minimal scenario which can reproduce the problem. |
|
No problem.. No change. no spam_status for the mail with "TEST_ANTISPAM" in the subject. |
|
|
The problem is the same with equal function : doesn't block anything. |
|
Very strange... I rollback the last patch, and "equal" line works again... |
|
Can you add this to output debug log? (note that --- a/src/lib/Sympa/Scenario.pm
+++ b/src/lib/Sympa/Scenario.pm
@@ -1105,6 +1105,7 @@ sub do_is_editor {
##### match
sub do_match {
+ $log->syslog('debug3', '(%s,%s,%s,%s)', @_);
my $that = shift;
my $condition_key = shift;
my @args = @_;
|
|
@fprigent, I might catch the tail of bug. Could you apply additional patch? (N.B.: See also #850 to find all patches shown by me in this issue page.) |
|
Strange. with the equal on a "header", filtering works... maybe it change something elsewhere... The patch is applied this is spam_status file this is the include.send.header file and it doesn't works. |
|
Le 25/01/2020 à 08:27, IKEDA Soji a écrit :
There may be any patches not yet applied. If possible, please rollback
to 6.2.52-1 RPM and apply patches #842
<#842>, #847
<#847>, #848
<#848> and #850
<#850> again.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#849?email_source=notifications&email_token=AC2APY6KIE2TZVFJBZ3B3HDQ7PSUTA5CNFSM4KLAXXT2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEJ4XGTY#issuecomment-578384719>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AC2APYYCCNCLEXWR6GL76D3Q7PSUTANCNFSM4KLAXXTQ>.
Strange behaviour :
patch 842 and the 2 patches of 847 are OK but 848 fail...
patch -p4 Scenario.pm 182d6e7.patch
patch -p4 Scenario.pm 6f811ae.patch
patch -p4 Scenario.pm 2aace48.patch
[root@sympa Sympa]# patch -p4 Scenario.pm
a43c262.patch
patching file Scenario.pm
Hunk #1 FAILED at 2108.
Hunk #2 FAILED at 2180.
2 out of 2 hunks FAILED -- saving rejects to file Scenario.pm.rej
|
|
Le 25/01/2020 à 08:27, IKEDA Soji a écrit :
There may be any patches not yet applied. If possible, please rollback
to 6.2.52-1 RPM and apply patches #842
<#842>, #847
<#847>, #848
<#848> and #850
<#850> again.
Facepalm !!!
I forgot it's not on Scenario.pm ...
… —
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#849?email_source=notifications&email_token=AC2APY6KIE2TZVFJBZ3B3HDQ7PSUTA5CNFSM4KLAXXT2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEJ4XGTY#issuecomment-578384719>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AC2APYYCCNCLEXWR6GL76D3Q7PSUTANCNFSM4KLAXXTQ>.
|
|
I should go out (my daugther school).. I will come back later. |
|
A missing patch ? |
|
|
|
No effect : |
|
But I confirmed |
|
equal() does not always work as expected. We’d be better to focus on match(). Can you show the content of message you sent? I’ll try using it on my host. |
|
I agree. Equal is only a workaround. |
|
I prepared test cases with minimized test data. Please use them if you prefer. Patches
Configuration Following minimal scenario files are used (they are saved in
Test messages (a) Spam message (b) Non-spam message Test cases
|
|
I tried with another header same behaviour. |
|
Could you please check test cases above at first? And then, if you changed anything, please tell us where you changed and what is the result. |
|
I show you my perl libraries |
|
Better ! I first did test with my configuration.. And it works.. What should be blocked is blocked, and what shouldn't, isn't. |
|
strange.. I didn't find "because tagged as spam" even in the case just above.. |
|
worst : I only had this sentences 2 times in this week. But "equal" successed more than 3 times, and none of the lines show a "sympa-test" |
|
Did you perform my test using the same patches (see note), configuration and test data? Please confirm. |
|
I am preparing the test with your test case. I haven't done them yet. But I applied your last modification (37815ce.patch) |
|
I will recheck all. |
|
To much line in my sympa process I have to wait that all initialization is ended between each test. |
|
I tried to reduce log level... No message... I had done with your test case. First case : match on HEADER only in spam_statusspam_status.x-spam-status include.send.status Result: Second case : nomatch in spam_status ONLY on header in include.send.headerspam_status.x-spam-status include.send.status Result: So It works, but it doesn't say it... |
|
|
|
|
nope it was "include.send.header". I mistype in github... ;-). for journald, configuration is OK (as far as I understood) but even without, there is no journald message before of after, and there are some Sympa:Spindle message : |
|
Please check log_level parameter in sympa.conf. If rsyslogd missed some logs, set log_socket_type in sympa.conf to “inet” and enable TCP or UDP listening socket in rsyslogd.conf. |
|
It makes me crazy... I have done this in Sympa/Spindle/DoCommand.pm no file /tmp/log_spam. I have put "log_level 3" for debugging, no "DoCommand", despite "zillions" of lignes.. I have do this on the "normal" log (notice or better), previous upgrading (sympa 6.2.48) and with the 6.2.52_patch_850 In the last one, there is no "DoCommand". and before, there are. |
|
You are mixing logs given by several processes. On this issue, we may focus only on |
|
Attached files are results of test cases above on my host. Some excerpts are shown in below.
|
|
There must be something special on my host. But I don't know what. I verify rpm (rpm -V) and only modified parts are shown.
I will try to investigate further... Thanks for your help. The objective was : it works, and it blocks spam.. It's done. It logs for you, so you can close the case. I will reopen it if I found what's wrong... |
|
Ok, this issue is closed for the present. Please feel free to reopen it if you want. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Very strange behaviour. Unable to reactivate spam scenario, or even to block a mail in scenario with pure "match" filter. All worked with 2.6.48
Version
6.2.52 with patch #847
Installation method
yum from sympa-ja
Expected behavior
Filtering spam by sending them in moderation spool with a "Trash" indicator.
Actual behavior
No filtering, not even a "Trash" on mail if they have to be moderated.
Additional information
my include.send.header
my spam_status.x-spam-status (I have 2 antispam : dspam and rspamd)
I tried to change header with msg_header, I tried to directly put the s-spam-status scenario in include.send.header.
I reload completely sympa each time.
I can't see any "cache" or something like that. Maybe in DB ?
The "pre-compilation" of scenario are OK 👍
and
The text was updated successfully, but these errors were encountered: