You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Sebastian Wolfgarten <se...@wolfgarten.com> on 2016/01/01 19:37:26 UTC
Support for custom rule, rule seems to be ignored
Dear all,
I wish you and your families a happy, prosperous and healthy year 2016!
As for me, I am spending the first day of the new year battling with some custom SA rule that seems to be ignored:
header FR_Spam2 Received =~ /e\d{1,2}+\.(.*)\.fr/i
score FR_Spam2 3.5
Is this rule correct from a syntactical perspective? I would say yes as pcregrep is fine with it.
Anyway, here is the scenario that I am trying to handle: I am getting *lots* of spam messages in French with random text with each of them contains a line like "Received from e(1 or 2 digit number).(some random hostname sometimes with dashes and sometimes without).fr“ - here is an example:
(...)
Received: from e4.mailsclub.fr (e4.mailsclub.fr [212.83.145.185])
by mail.wolfgarten.com (Postfix) with ESMTP id 359217DCC0
for <se...@wolfgarten.com>; Fri, 1 Jan 2016 11:47:01 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; s=key; d=e4.mailsclub.fr;
h=Message-ID:Date:Subject:From:Reply-To:To:MIME-Version:Content-Type:List-Unsubscribe; i=send@e4.mailsclub.fr;
bh=gbtf9vK5d2PMdkJu/hIUduylbcQ=;
b=t2BrXmPpOX3yVZ1kMGZzm+aIE2nTKU02gxlG8jwOsxrHGdXWDnbQxrmaOU5xcDw5It1UDA4jxw+b
2XJET5xUV/c66L6hwxtOt757o1F1UD2ezM+sd0BHAh9LjTV+icb4k38w89FwHHumycRj2V2xh/3G
imoFha6WLhNxDVsKSQY=
DomainKey-Signature: a=rsa-sha1; c=nofws; q=dns; s=key; d=e4.mailsclub.fr;
b=k0K9oJ5XP+rOa4oSNa3ZWJ1gCWdnu7khO+hdWAOJv7trKEAlZ0IHfSGRWwWq+4cl1xUnVqv6I2G3
z6pROvLHeaPo7Ue2K5MQzZUA/VFDhDApEMEc7bBr5cB3mpxfSAUo69eZDtPyLsjCd27LMQ+FMGwi
xddezXrzEhGlMeVLsHw=;
(...)
Any thoughts on how to best deal with this?
Many thanks.
Kind regards
Sebastian
Re: Support for custom rule, rule seems to be ignored
Posted by Sebastian Wolfgarten <se...@wolfgarten.com>.
Dear Kevin,
many thanks for your quick response. Unfortunately, there is no output generated except for a warning message that I have no description defined for my custom rule:
# spamassassin -tD < ./test\:2\,Sdj 2>&1 | grep -i FR_Spam2
Jan 1 20:08:56.590 [60105] dbg: config: warning: no description set for FR_Spam2
Any other thoughts? Ideas?
Many thanks.
Best regards
Sebastian
> Am 01.01.2016 um 19:52 schrieb Kevin A. McGrail <KM...@PCCC.com>:
>
> On 1/1/2016 1:37 PM, Sebastian Wolfgarten wrote:
>> Dear all,
>>
>> I wish you and your families a happy, prosperous and healthy year 2016!
>>
>> As for me, I am spending the first day of the new year battling with some custom SA rule that seems to be ignored:
>>
>> header FR_Spam2 Received =~ /e\d{1,2}+\.(.*)\.fr/i
>> score FR_Spam2 3.5
>>
>> Is this rule correct from a syntactical perspective? I would say yes as pcregrep is fine with it.
>>
>> Anyway, here is the scenario that I am trying to handle: I am getting *lots* of spam messages in French with random text with each of them contains a line like "Received from e(1 or 2 digit number).(some random hostname sometimes with dashes and sometimes without).fr“ - here is an example:
> I suggest you run it through spamassassin on the command line with -D and check the output. spamassassin -tD < sample-spam.txt 2>&1 | grep -i FR_Spam2
>
> My off the cuff guess is perhaps you are using a glue that tests the spam before that received line is added to the email.
>
> Regards,
> KAM
Re: Support for custom rule, rule seems to be ignored
Posted by "Kevin A. McGrail" <KM...@PCCC.com>.
On 1/1/2016 1:37 PM, Sebastian Wolfgarten wrote:
> Dear all,
>
> I wish you and your families a happy, prosperous and healthy year 2016!
>
> As for me, I am spending the first day of the new year battling with some custom SA rule that seems to be ignored:
>
> header FR_Spam2 Received =~ /e\d{1,2}+\.(.*)\.fr/i
> score FR_Spam2 3.5
>
> Is this rule correct from a syntactical perspective? I would say yes as pcregrep is fine with it.
>
> Anyway, here is the scenario that I am trying to handle: I am getting *lots* of spam messages in French with random text with each of them contains a line like "Received from e(1 or 2 digit number).(some random hostname sometimes with dashes and sometimes without).fr“ - here is an example:
I suggest you run it through spamassassin on the command line with -D
and check the output. /spamassassin/ -tD < sample-spam.txt /2/>/&1/ |
grep -i FR_Spam2
My off the cuff guess is perhaps you are using a glue that tests the
spam before that received line is added to the email.
Regards,
KAM
Re: Support for custom rule, rule seems to be ignored
Posted by John Hardin <jh...@impsec.org>.
On Sat, 2 Jan 2016, Bill Cole wrote:
> On 2 Jan 2016, at 9:11, RW wrote:
>
>> 1. \d{1,2}+ doesn't make any sense, you need either {1,2} or +
>
> It's a bit esoteric, but here's what the perlre man page says:
>
> {n,m}+ Match at least n but not more than m times and give nothing
> back
>
> Put another way: possessive but not greedy. In some REs it is useful to
> prevent backtracking. In this one there's no chance of that, but its
> harmless.
That syntax may introduce dependencies on which version of perl is
installed.
--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
If guards and searches and metal detectors can't keep a gun out of
a maximum-security solitary confinement prisoner's cell, how will
a disciplinary policy and some signs keep guns out of a university?
-----------------------------------------------------------------------
12 days since the first successful real return to launch site (SpaceX)
Re: Support for custom rule, rule seems to be ignored
Posted by Bill Cole <sa...@billmail.scconsult.com>.
On 2 Jan 2016, at 9:11, RW wrote:
> 1. \d{1,2}+ doesn't make any sense, you need either {1,2} or +
It's a bit esoteric, but here's what the perlre man page says:
{n,m}+ Match at least n but not more than m times and give
nothing back
Put another way: possessive but not greedy. In some REs it is useful to
prevent backtracking. In this one there's no chance of that, but its
harmless.
Re: Support for custom rule, rule seems to be ignored
Posted by Sebastian Wolfgarten <se...@wolfgarten.com>.
Hi,
many thanks for your feedback. This is to confirm the following rule seems to work:
header French_Spam10 ALL =~ / e\d{1,2}\.\S+\.fr /i
score French_Spam10 3.5
Many thanks for all those that supported me in the troubleshooting process.
Best regards
Sebastian
> Am 02.01.2016 um 15:11 schrieb RW <rw...@googlemail.com>:
>
> On Fri, 1 Jan 2016 19:37:26 +0100
> Sebastian Wolfgarten wrote:
>
>> Dear all,
>>
>> I wish you and your families a happy, prosperous and healthy year
>> 2016!
>>
>> As for me, I am spending the first day of the new year battling with
>> some custom SA rule that seems to be ignored:
>>
>> header FR_Spam2 Received =~ /e\d{1,2}+\.(.*)\.fr/i
>> score FR_Spam2 3.5
>>
>> Is this rule correct from a syntactical perspective? I would say yes
>> as pcregrep is fine with it.
>
> I tested it and it worked for me. Perhaps you need to to restart spamd.
>
> However there are some problems:
>
> 1. \d{1,2}+ doesn't make any sense, you need either {1,2} or +
>
> 2. .* can extend the match into a different hostname, \S+ would be
> better
>
> 3. consider adding a space at both ends
Re: Support for custom rule, rule seems to be ignored
Posted by RW <rw...@googlemail.com>.
On Fri, 1 Jan 2016 19:37:26 +0100
Sebastian Wolfgarten wrote:
> Dear all,
>
> I wish you and your families a happy, prosperous and healthy year
> 2016!
>
> As for me, I am spending the first day of the new year battling with
> some custom SA rule that seems to be ignored:
>
> header FR_Spam2 Received =~ /e\d{1,2}+\.(.*)\.fr/i
> score FR_Spam2 3.5
>
> Is this rule correct from a syntactical perspective? I would say yes
> as pcregrep is fine with it.
I tested it and it worked for me. Perhaps you need to to restart spamd.
However there are some problems:
1. \d{1,2}+ doesn't make any sense, you need either {1,2} or +
2. .* can extend the match into a different hostname, \S+ would be
better
3. consider adding a space at both ends