You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Frank Gadegast <fr...@powerweb.de> on 2013/04/25 07:56:18 UTC
Re: rule problem basing on X-Spam-ASN - not a rule problem
Karsten Bräckelmann wrote:
>> Frank Gadegast skrev den 2013-04-24 16:45:
>>
>>> header LOCAL_AS6697 X-Spam-ASN =~ / AS6697 /
>
> The ASN plugin documentation [1] shows the AS number at the beginning of
> the header's value. The leading space prevents your header rule from
> matching, and should instead even anchor the RE at the beginning.
>
> /^AS6697 /
Hm, I should have sayd, that I tried the rule even without any spacing,
with ancor, with whatever before and it didnt work.
Last test was like this, took a msg (from this list :o)
# spamassassin 2>&1 -D -t msg | grep X-Spam-ASN
X-Spam-ASN: AS3701 140.211.0.0/16
inserted the rule to match this one
header LOCAL_AS3356 X-Spam-ASN =~ /^AS3701 /
describe LOCAL_AS3356 Sender IP in AS from friendly SA user
score LOCAL_AS3356 -0.1
restarted SA and tested with
# spamassassin 2>&1 -D -t msg | grep LOCAL_AS
Nothing :o(
I still think its a problem, that SA
- either strips all X-Spam- lines out of the mail before starting
(and also strips the X-Spam-AS out)
- or starts its ruling business before the X-Spam-AS is applied
Any idea how to test the order ?
lint didnt really help here, debug neither ...
Kind regards, Frank
>
> [1] http://spamassassin.apache.org/full/3.3.x/doc/Mail_SpamAssassin_Plugin_ASN.html
>
>
> On Thu, 2013-04-25 at 00:32 +0200, Benny Pedersen wrote:
>> /\ AS6697\ /
>> space needs to be excaped, [...]
>
> Just... No.
>
>
PHADE Software - PowerWeb http://www.powerweb.de
Inh. Dipl.-Inform. Frank Gadegast mailto:frank@powerweb.de
Schinkelstrasse 17 fon: +49 33200 52920
14558 Nuthetal OT Rehbruecke, Germany fax: +49 33200 52921
======================================================================
Re: rule problem basing on X-Spam-ASN - not a rule problem
Posted by Dave Funk <db...@engineering.uiowa.edu>.
On Thu, 25 Apr 2013, Frank Gadegast wrote:
> And SA is doing it right, to remove all X-Spam-lines
> before its starting, so that spammer cannot trick SA.
>
> And whatever line is inserted by ASN.pm, it needs
> to be stripped too, and thats why its programmed
> like it is.
>
> But I have no still no idea how to get it done in a
> perfect order, like the following
>
> - SA strips the X-Spam-lines
> - ASN.pm inserts its line including the AS
> - SA runs its rules and triggeres also on the X-Spam-ASN-line
>
> Is it time to ask the developers or file a bug ?
This doesn't help unless the plugin adds a pseud-header but in the
case of plugins that do, you can change the priority of your
rules to get them to run after the plugin.
I ran into this issue when writing rules to check the results of the
ClamAV plugin.
EG, in my "clamav.cf" file I invoke the plugin with an "eval" then have
rules to trigger off the pseudo-header that it adds. In the rules I have
lines like:
#loadplugin ClamAV /etc/mail/spamassassin/plugins/clamav.pm now done in v310.pre
#
full L_CLAMAV eval:check_clamav()
describe L_CLAMAV Clam AntiVirus detected a virus
score L_CLAMAV 3
#
header T__MY_CLAMAV X-Spam-Virus =~ /Yes/i
header T__MY_CLAMAV_SANE X-Spam-Virus =~ /Yes.{1,50}Sanesecurity/i
header T__MY_CLAMAV_MSRBL X-Spam-Virus =~ /Yes.{1,50}(?:MSRBL|MBL)/
header T__MY_CLAMAV_PHISH X-Spam-Virus =~ /Yes.{1,50}Phish/
header L_UI_PHISHs X-Spam-Virus =~ /Yes.{1,50}Phishing/
# Need to set the 'X-Spam-Virus' header rules to a "high" priority
# so they run late and will be evaluated -after- the plugin runs
priority T__MY_CLAMAV 9999
priority T__MY_CLAMAV_SANE 9999
priority T__MY_CLAMAV_MSRBL 9999
priority T__MY_CLAMAV_PHISH 9999
priority L_UI_PHISHs 9999
#
meta MY_CLAMAV_SANE (L_CLAMAV && T__MY_CLAMAV_SANE)
meta MY_CLAMAV_MSRBL (L_CLAMAV && T__MY_CLAMAV_MSRBL)
[snip..]
--
Dave Funk University of Iowa
<dbfunk (at) engineering.uiowa.edu> College of Engineering
319/335-5751 FAX: 319/384-0549 1256 Seamans Center
Sys_admin/Postmaster/cell_admin Iowa City, IA 52242-1527
#include <std_disclaimer.h>
Better is not better, 'standard' is better. B{
Re: rule problem basing on X-Spam-ASN - not a rule problem
Posted by Frank Gadegast <fr...@powerweb.de>.
Christian Recktenwald wrote:
> On Thu, Apr 25, 2013 at 10:18:43AM +0200, Frank Gadegast wrote:
>> And SA surely strips all head-lines starting with "X-Spam-" before
>> its doing anything.
>
> In Mail/SpamAssassin.pm there is some special handling of
> "X-Spam-" prefixed mail headers.
> So it's really not about subsequent dashes.
>
Yes, it says:
Returns the text of the message, with any SpamAssassin-added text (such
as the report, or X-Spam-Status headers) stripped.
And the code looks like
# remove any other X-Spam headers we added, will be unfolded
$hdrs = "\n".$hdrs; # simplifies regexp below
1 while $hdrs =~ s/\nX-Spam-.*\n/\n/g;
$hdrs =~ s/^\n//;
And SA is doing it right, to remove all X-Spam-lines
before its starting, so that spammer cannot trick SA.
And whatever line is inserted by ASN.pm, it needs
to be stripped too, and thats why its programmed
like it is.
But I have no still no idea how to get it done in a
perfect order, like the following
- SA strips the X-Spam-lines
- ASN.pm inserts its line including the AS
- SA runs its rules and triggeres also on the X-Spam-ASN-line
Is it time to ask the developers or file a bug ?
Kind regards, Frank
--
MOTD: "have you enabled SSL on a website or mailbox today ?"
--
PHADE Software - PowerWeb http://www.powerweb.de
Inh. Dipl.-Inform. Frank Gadegast mailto:frank@powerweb.de
Schinkelstrasse 17 fon: +49 33200 52920
14558 Nuthetal OT Rehbruecke, Germany fax: +49 33200 52921
======================================================================
Re: rule problem basing on X-Spam-ASN - not a rule problem
Posted by Christian Recktenwald <sp...@citecs.de>.
On Thu, Apr 25, 2013 at 10:18:43AM +0200, Frank Gadegast wrote:
> And SA surely strips all head-lines starting with "X-Spam-" before
> its doing anything.
In Mail/SpamAssassin.pm there is some special handling of
"X-Spam-" prefixed mail headers.
So it's really not about subsequent dashes.
--
Christian Recktenwald
spamassassin-talk-dist@citecs.de
Re: rule problem basing on X-Spam-ASN - not a rule problem
Posted by Benny Pedersen <me...@junc.eu>.
Frank Gadegast skrev den 2013-04-25 10:18:
> But it looks like add_header can only be used to insert lines
> starting
> with X-Spam-, is there any other way to tell SA to insert a header
> line
> wich is starting with something else ?
there is a well dokumented reason for not have it possible to add
anything other then X-Spam-foo, if it was not templated sa could not
remove headers again safely, leading to forged sa reports that this
email is not spam, when it not tested localy
--
senders that put my email into body content will deliver it to my own
trashcan, so if you like to get reply, dont do it
Re: rule problem basing on X-Spam-ASN - not a rule problem
Posted by Frank Gadegast <fr...@powerweb.de>.
Christian Recktenwald wrote:
> I ran some tests which indicate one may not have subsequent '-' after
> 'X-' in header lines:
Thats a great test, many thnx for it.
It simply indicates, that ASN.pm is running nearly at first, before
SA does its messurements.
And SA surely strips all head-lines starting with "X-Spam-" before
its doing anything.
So, its not a bug of SA itself, its rather a problem of ASN.pm
ASN.pm should insert something else, like
X-ASN or so and should strip this line of itself, before it starts ...
Maybe
add_header all ASN _ASN_ _ASNCIDR_
should be modifified ?
But it looks like add_header can only be used to insert lines starting
with X-Spam-, is there any other way to tell SA to insert a header line
wich is starting with something else ?
Kind regards, Frank
>
> given this "message":
>
> X-SpamASN: AS3701 140.211.0.0/16
> X-Spam-ASN: AS3701 140.211.0.0/16
>
> body...
>
> and those rules:
>
> header _LOCAL_XAS1 X-SpamASN =~ /AS3701 /
> describe _LOCAL_XAS1 Sender IP in AS from friendly SA user
> score _LOCAL_XAS1 -0.1
>
> header _LOCAL_XAS2 X-Spam-ASN =~ /AS3701 /
> describe _LOCAL_XAS2 Sender IP in AS from friendly SA user
> score _LOCAL_XAS2 -0.1
>
> _LOCAL_XAS1 matches and _LOCAL_XAS2 does not:
>
> pts rule name description
> ---- ---------------------- --------------------------------------------------
> -0.1 _LOCAL_XAS1 Sender IP in AS from friendly SA user
> -0.0 NO_RELAYS Informational: message was not relayed via SMTP
> 1.6 SUBJ_ALL_CAPS Subject is all capitals
> 1.2 MISSING_HEADERS Missing To: header
> 0.1 MISSING_MID Missing Message-Id: header
> -0.0 NO_RECEIVED Informational: message has no Received headers
> 1.4 MISSING_DATE Missing Date: header
> 0.0 NO_HEADERS_MESSAGE Message appears to be missing most RFC-822 headers
>
> perhaps this might be worth a bug report.
--
MOTD: "have you enabled SSL on a website or mailbox today ?"
--
PHADE Software - PowerWeb http://www.powerweb.de
Inh. Dipl.-Inform. Frank Gadegast mailto:frank@powerweb.de
Schinkelstrasse 17 fon: +49 33200 52920
14558 Nuthetal OT Rehbruecke, Germany fax: +49 33200 52921
======================================================================
Re: rule problem basing on X-Spam-ASN - not a rule problem
Posted by Benny Pedersen <me...@junc.eu>.
Christian Recktenwald skrev den 2013-04-25 08:56:
> perhaps this might be worth a bug report.
it will just delay sa 3.4.x even more, and it would be marked invalid,
if it does not work, check local add headers, docs is "perldoc
Mail::SpamAssassin::Conf"
--
senders that put my email into body content will deliver it to my own
trashcan, so if you like to get reply, dont do it
Re: rule problem basing on X-Spam-ASN - not a rule problem
Posted by Christian Recktenwald <sp...@citecs.de>.
I ran some tests which indicate one may not have subsequent '-' after
'X-' in header lines:
given this "message":
X-SpamASN: AS3701 140.211.0.0/16
X-Spam-ASN: AS3701 140.211.0.0/16
body...
and those rules:
header _LOCAL_XAS1 X-SpamASN =~ /AS3701 /
describe _LOCAL_XAS1 Sender IP in AS from friendly SA user
score _LOCAL_XAS1 -0.1
header _LOCAL_XAS2 X-Spam-ASN =~ /AS3701 /
describe _LOCAL_XAS2 Sender IP in AS from friendly SA user
score _LOCAL_XAS2 -0.1
_LOCAL_XAS1 matches and _LOCAL_XAS2 does not:
pts rule name description
---- ---------------------- --------------------------------------------------
-0.1 _LOCAL_XAS1 Sender IP in AS from friendly SA user
-0.0 NO_RELAYS Informational: message was not relayed via SMTP
1.6 SUBJ_ALL_CAPS Subject is all capitals
1.2 MISSING_HEADERS Missing To: header
0.1 MISSING_MID Missing Message-Id: header
-0.0 NO_RECEIVED Informational: message has no Received headers
1.4 MISSING_DATE Missing Date: header
0.0 NO_HEADERS_MESSAGE Message appears to be missing most RFC-822 headers
perhaps this might be worth a bug report.
--
Christian Recktenwald
spamassassin-talk-dist@citecs.de