Re: CHAOS: v1.2.2: Of Documentation

[Henrik K]

On Fri, Jul 23, 2021 at 12:07:52AM -0400, Jared Hall wrote:
> 
> 1) The module, if installed and using the config file as is, does no harm at
> all.  It will merely generate rules based upon what it finds.  These are all
> scored at the low rate of 0.01.  It's up to the user to decide what to with
> them.  They can wrap up a generated rule in a meta rule.  Example:
> 
> meta   JR_HATES_BEENTHERE   (JR_X_BEENTHERE)
> score JR_HATES_BEENTHERE   8.0

While I guess it's not illegal to whip up rules on the fly, it's awkward and
inflexible for the users.

> 2C) The initial release of CHAOS.pm did all kinds of scoring.  One of the
> knocks I have about SpamAssassin is that is does not maintain counts of hits. 
> My complaints about this go all the way back to 2010.  Counts and Amounts.  SA
> is great with Amounts.  It sucks with Counts.  To the SA Development crew's
> credit, somewhere along the way, tflags were added to allow that functionality
> in a very primitive fashion.  Many people are happy with that.  I'm just not
> one of them.
> ...
> I read somewhere, while looking at META rules that SA internally builds an
> array of the rules hit.  That way, as rules hit, METAs are then appropriately
> updated.  Gee, an array.  Maybe we could add a count to that array if the user
> wishes to?  I think that it is a lot of development; not so much the actual
> process of doing it, but updating all the User handling thereof.  Alas, It is
> what it is *SIGH*

There's zero actual information here.  What exactly are you finding hard to
"count"?

Re: CHAOS: v1.2.2: Of Documentation

[Charles Sprickman]

What would the elevator pitch be for this?

> On Jul 23, 2021, at 12:07 AM, Jared Hall  wrote:
> 
> Simon Wilson wrote:
>>> could you, please, finally, describe what does this module do,
>>> here to the list and/or to the wiki?
>>> 
>>> the description there is too hard to understand, epecially at the beginning,
>>> and I couldn't force myself to understand it (multiple times).
>>> 
>>> Maybe you should start with the easy parts and follow with those more
>>> compliated functionality, because I feel the description starts with 
>>> thelatter.
>> 
>> I'm guessing from the silence in response that this will remain a mystery.
>> 
>> Simon.
>> 
>> ___
>> Simon Wilson
>> M: 0400 12 11 16
> 
> Reads perfectly well to me.  I guess to be compatible with any other plugin, 
> I must delete all documentation entirely :)  
> 
> Seriously, every single rule that this module can generate is listed.  That's 
> a good start, comparatively.
> 
> I answer, and have answered, all questions regarding this module.  Open-ended 
> questions, or questions that are vague and ambiguous, are ignored.  For 
> instance, "Maybe you should start with easy parts"?  OK, what's easy?  I'm 
> reminded of an old Star Trek episode where Dr. McCoy is reattaching Spock's 
> brain.  "It's so easy.  A child can do it", he muses.  Questions have value.  
> Statements less so.
> 
> This module has some unique stuff that CANNOT be done in a pure SpamAssassin 
> environment.  It also has stuff that can be replicated using standard rules.  
> 
> 1) The module, if installed and using the config file as is, does no harm at 
> all.  It will merely generate rules based upon what it finds.  These are all 
> scored at the low rate of 0.01.  It's up to the user to decide what to with 
> them.  They can wrap up a generated rule in a meta rule.  Example:
> 
> meta   JR_HATES_BEENTHERE   (JR_X_BEENTHERE)
> score JR_HATES_BEENTHERE   8.0
> 
> 2) Via a configuration file option, "chaos_mode", the module can be set to 
> automatically score its rules.
> 
> chaos_mode AutoISP
> 
> It will still run along with existing files, cranking out higher scores for 
> those rules marked with an asterisk.  That is still probably acceptable for 
> most people.  But it can cause problems.  The popular KAM ruleset scores 
> SendGrid Emails with a high value.  Mine is split into two different values 
> that are scored differently.  While they are both lower than KAM's, combined, 
> I see that as a potential problem.  I have no knowledge of what somebody's 
> rules are at any given moment.  Caveat Emptor.  There I go again with the 
> Latin :)
> 
> 2A) What values do I set for these rules?  As a percentage of another 
> configuration file option, "chaos_tag":
> 
> chaos_tag 7
> 
> Per the example above JR_X_BEENTHERE is a rule that is Auto-Scored.  If you 
> lower the chaos_tag value, the score for this rule would be reduced.  If I 
> increase the chaos_tag value, the score produced by this rule is raised.
> 
> 2B) The AutoISP mode, as is, should be fine for anybody running  a spam tag 
> level of 8 to 12.  
> 
> 2C) The initial release of CHAOS.pm did all kinds of scoring.  One of the 
> knocks I have about SpamAssassin is that is does not maintain counts of hits. 
>  My complaints about this go all the way back to 2010.  Counts and Amounts.  
> SA is great with Amounts.  It sucks with Counts.  To the SA Development 
> crew's credit, somewhere along the way, tflags were added to allow that 
> functionality in a very primitive fashion.  Many people are happy with that.  
> I'm just not one of them.
> 
> I read somewhere, while looking at META rules that SA internally builds an 
> array of the rules hit.  That way, as rules hit, METAs are then appropriately 
> updated.  Gee, an array.  Maybe we could add a count to that array if the 
> user wishes to?  I think that it is a lot of development; not so much the 
> actual process of doing it, but updating all the User handling thereof.  
> Alas, It is what it is *SIGH*
> 
> 2D) One thing about running AutoISP mode is that you can change a Rule's name 
> in the configuration file and not matter what, you'll get the Rulename that's 
> hard-coded into the program.  When a Eval plugin function is called, SA 
> passes the rule name to the plugin.  Most plugins just ignore it, and simply 
> return a Hit/Miss value for the Rulename.  I ignore that completely.
> 
> 2E) When I first released CHAOS, all it did was Automatic Scoring.  And I 
> used all kinds of fancy algorithms, even logarithmic, to demonstrate that.  
> That was pointless, as many pointed out at the time.  I don't do that stuff 
> anymore.
> 
> 2F) Still, as is, AutoISP will still work great for most people. 
> 
> 3) As the first release of CHAOS was about as successful as the Hindenburg, I 
> added the concept of Manual scoring.  This works in the same fashion as most 
> people are accustomed to.  This is set in the configuration file:
> 
> chaos_mode Manual
> 
> There 

CHAOS: v1.2.2: Of Documentation

[Jared Hall]

Simon Wilson wrote:

could you, please, finally, describe what does this module do,
here to the list and/or to the wiki?

the description there is too hard to understand, epecially at the 
beginning,

and I couldn't force myself to understand it (multiple times).

Maybe you should start with the easy parts and follow with those more
compliated functionality, because I feel the description starts with 
thelatter.



I'm guessing from the silence in response that this will remain a mystery.

Simon.

___
Simon Wilson
M: 0400 12 11 16


Reads perfectly well to me.  I guess to be compatible with any other 
plugin, I must delete all documentation entirely :)


Seriously, every single rule that this module can generate is listed.  
That's a good start, comparatively.


I answer, and have answered, all questions regarding this module. 
Open-ended questions, or questions that are vague and ambiguous, are 
ignored.  For instance, "Maybe you should start with easy parts"? OK, 
what's easy?  I'm reminded of an old Star Trek episode where Dr. McCoy 
is reattaching Spock's brain.  "It's so easy.  A child can do it", he 
muses.  Questions have value.  Statements less so.


This module has some unique stuff that CANNOT be done in a pure 
SpamAssassin environment.  It also has stuff that can be replicated 
using standard rules.


1) The module, if installed and using the config file as is, does no 
harm at all.  It will merely generate rules based upon what it finds.  
These are all scored at the low rate of 0.01.  It's up to the user to 
decide what to with them.  They can wrap up a generated rule in a meta 
rule.  Example:


meta   JR_HATES_BEENTHERE   (JR_X_BEENTHERE)
score JR_HATES_BEENTHERE   8.0
||
2) Via a configuration file option, "chaos_mode", the module can be set 
to automatically score its rules.


chaos_mode AutoISP

It will still run along with existing files, cranking out higher scores 
for those rules marked with an asterisk.  That is still probably 
acceptable for most people.  But it can cause problems. The popular KAM 
ruleset scores SendGrid Emails with a high value. Mine is split into two 
different values that are scored differently.  While they are both lower 
than KAM's, combined, I see that as a potential problem.  I have no 
knowledge of what somebody's rules are at any given moment.  Caveat 
Emptor.  There I go again with the Latin :)


2A) What values do I set for these rules?  As a percentage of another 
configuration file option, "chaos_tag":


chaos_tag 7

Per the example above JR_X_BEENTHERE is a rule that is Auto-Scored. If 
you lower the chaos_tag value, the score for this rule would be 
reduced.  If I increase the chaos_tag value, the score produced by this 
rule is raised.


2B) The AutoISP mode, as is, should be fine for anybody running  a spam 
tag level of 8 to 12.


2C) The initial release of CHAOS.pm did all kinds of scoring.  One of 
the knocks I have about SpamAssassin is that is does not maintain counts 
of hits.  My complaints about this go all the way back to 2010.  Counts 
and Amounts.  SA is great with Amounts.  It sucks with Counts.  To the 
SA Development crew's credit, somewhere along the way, tflags were added 
to allow that functionality in a very primitive fashion.  Many people 
are happy with that.  I'm just not one of them.


I read somewhere, while looking at META rules that SA internally builds 
an array of the rules hit.  That way, as rules hit, METAs are then 
appropriately updated.  Gee, an array.  Maybe we could add a count to 
that array if the user wishes to?  I think that it is a lot of 
development; not so much the actual process of doing it, but updating 
all the User handling thereof.  Alas, It is what it is *SIGH*


2D) One thing about running AutoISP mode is that you can change a Rule's 
name in the configuration file and not matter what, you'll get the 
Rulename that's hard-coded into the program.  When a Eval plugin 
function is called, SA passes the rule name to the plugin. Most plugins 
just ignore it, and simply return a Hit/Miss value for the Rulename.  I 
ignore that completely.


2E) When I first released CHAOS, all it did was Automatic Scoring. And I 
used all kinds of fancy algorithms, even logarithmic, to demonstrate 
that.  That was pointless, as many pointed out at the time.  I don't do 
that stuff anymore.


2F) Still, as is, AutoISP will still work great for most people.

3) As the first release of CHAOS was about as successful as the 
Hindenburg, I added the concept of Manual scoring.  This works in the 
same fashion as most people are accustomed to.  This is set in the 
configuration file:


chaos_mode Manual

There are currently two exceptions in Manual mode.  I don't allow 
changing Rulenames for the mailer_check() and id_attachments() Eval 
functions.  The reason is that these Evals can produce a lot of Rule 
outputs.



OK, are you still with me?  If not, just implement Step 1) above.

4) Regarding overall development,  

Re: CHAOS: v1.2.1 Released

[Simon Wilson]

 - Message from Matus UHLAR - fantomas  -
   Date: Mon, 19 Jul 2021 18:48:15 +0200
   From: Matus UHLAR - fantomas 
Subject: Re: CHAOS: v1.2.1 Released
     To: users@spamassassin.apache.org


On 19.07.21 10:43, Jared Hall wrote:

CHAOS.pm: Callouts, Handlers, And Other Stuff

https://github.com/telecom2k3/CHAOS

Version
1.2.1

Date: July 19.2021

* Corrected a regex in the Fraud Baud(y) rules where a normalized UTF8
character appeared un-hexed.
* Additional Fraud Subject and Fraud Body rules added.
* Additional duplicate Exchange Header rule added.
* New User-Agents added.
* New X-Mailers added.
* Fixed erroneous header match in check_email_greets Eval that
triggered during during SA lint check.

   Notes

There are no configuration file changes needed in this release.


could you, please, finally, describe what does this module do,
here to the list and/or to the wiki?

the description there is too hard to understand, epecially at the beginning,
and I couldn't force myself to understand it (multiple times).

Maybe you should start with the easy parts and follow with those more
compliated functionality, because I feel the description starts with  
thelatter.


I'm guessing from the silence in response that this will remain a mystery.

Simon.
 ___
Simon Wilson
M: 0400 12 11 16

Re: Matching on X-Spam headers doesn't get a hit

[RW]

On Thu, 22 Jul 2021 20:09:19 +0300
Henrik K wrote:

> On Thu, Jul 22, 2021 at 08:06:15PM +0300, Henrik K wrote:
> > On Thu, Jul 22, 2021 at 05:15:54PM +0200, Martin Flygenring wrote:  
> > >
> > > Is there a limitation to SpamAssassin so it doesn't accept
> > > looking for the two X-Spam-headers, or can you spot why this rule
> > > isn't matching?  
> > 
> > SA removes all X-Spam-* headers from the message, it's not possible
> > to match on them.  
> 
> ... except with a kludgy full rule that matches the whole pristine
> message:
> 
> full X_SPAM_FOOBAR /^X-Spam-Foobar: xyz/m

There's no perfect way of doing this. The above has the problem of
going through the whole email, including big attachment. It can also
match falsely inside the body.

The test can be constrained within the headers, but that causes problems
with the debug capture.

This version captures a lot too much:

 full X_SPAM_FOOBAR /^(?:.+\n)*X-Spam-Foobar: xyz/

This version capture nothing:

 full X_SPAM_FOOBAR /^(?=(?:.+\n)*X-Spam-Foobar: xyz)/

I'd go for the latter.

All of the above is untested.

Re: Matching on X-Spam headers doesn't get a hit

[Henrik K]

On Thu, Jul 22, 2021 at 08:06:15PM +0300, Henrik K wrote:
> On Thu, Jul 22, 2021 at 05:15:54PM +0200, Martin Flygenring wrote:
> >
> > Is there a limitation to SpamAssassin so it doesn't accept looking for the
> > two X-Spam-headers, or can you spot why this rule isn't matching?
> 
> SA removes all X-Spam-* headers from the message, it's not possible to match
> on them.

... except with a kludgy full rule that matches the whole pristine message:

full X_SPAM_FOOBAR /^X-Spam-Foobar: xyz/m

Re: Matching on X-Spam headers doesn't get a hit

[Henrik K]

On Thu, Jul 22, 2021 at 05:15:54PM +0200, Martin Flygenring wrote:
>
> Is there a limitation to SpamAssassin so it doesn't accept looking for the
> two X-Spam-headers, or can you spot why this rule isn't matching?

SA removes all X-Spam-* headers from the message, it's not possible to match
on them.

Re: Matching on X-Spam headers doesn't get a hit

[Jared Hall]

Martin Flygenring wrote:

Hi.

I'm trying to write a rule that matches on a mail that has the 
following headers:

X-Spam-Reasons: {'verdict': 'phishing',
 'spamcause': 
'gggruggvucftvghtrhhoucdtuddrgedvtddruddvgddugecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfkpffvgfftoffgfffktedpqfgfvfenuceurghilhhouhhtmecufedttdenucgorfhhihhshhhinhhgqdfkphfpvghtfihorhhkucdlfedttddmnecujfgurhephffvufffkfggtghisehrtdefvcdttddtnecuhfhrohhmpegtohhmphhlvghtvghtvghnuggvrhhsrdgtohhmucfuvghrvhgvrhcukffvuceouggrnhesshhhihhptghsuddrtghomheqnecuggftrfgrthhtvghrnhepleeiudeikeejffetgeetleeggfegteeghfdtveduvdekhedvlefgvedtueeiffejnecuffhomhgrihhnpeifvggsrdgrphhpnecukfhppeegtddrjeegrdduudefrddvgeeinecurfhhihhshhhinhhgkfhppfgvthifohhrkhepgedtrdejgedruddufedrvdegieenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepihhnvghtpefpohhnvgdpmhgrihhlfhhrohhmpegurghnsehshhhiphgtshdurdgtohhmpdhrtghpthhtohepmhgrthhthhgvfiestghomhhplhgvthgvthgvnhguvghrshdrtghomh',

 'elapsed': '4ms'}
X-AES-Category: SPAM
X-Spam-Category: PHISHING


This is the rules i have so far:
header  __HDR_XSPAM_CAT X-Spam-Category =~ 
/^(spam|phishing)$/i
header  __HDR_XSPAM_REASONS  X-Spam-Reasons =~ 
/['"](spam|phishing)['"]/i
header  __HDR_XAES_CAT  X-AES-Category =~ 
/^(spam|phishing)$/i
meta    SENDER_SPAM (__HDR_XSPAM_CAT || 
__HDR_XSPAM_REASONS || __HDR_XAES_CAT)
describe    SENDER_SPAM Message contains headers from 
sender indicating this is spam or phishing

scores  SENDER_SPAM 1


The only one that i can get working is the _HDR_XAES_CAT, both 
__HDR_XSPAM rules aren't hitting anything:

$ spamassassin -t -p ~/.spamassassin/mx teKbdz1W.txt -D 2>&1 | grep __HDR
Jul 22 17:00:53.480 [96] dbg: rules: ran header rule 
__HDR_XAES_CAT ==> got hit: "SPAM"
Jul 22 17:00:54.439 [96] dbg: check: 
subtests=__ANY_IMAGE_ATTACH,__ANY_TEXT_ATTACH,__ANY_TEXT_ATTACH_DOC,__BODY_INVOICE_EN,__BODY_TEXT_LINE(3),__CT,__CTYPE_HAS_BOUNDARY,__CTYPE_MULTIPART_ANY,__DKIM_DEPENDABLE,__DKIM_EXISTS,__DOS_HAS_ANY_URI,__DOS_RCVD_MON,__DOS_RELAYED_EXT,__ENV_AND_HDR_FROM_MATCH,__E_LIKE_LETTER(55),__FORGED_RCVD_TRAIL,__FROM_ADMIN,__FROM_DOM_ADMIN,__HAS_ANY_EMAIL,__HAS_ANY_URI,__HAS_DATE,__HAS_DKIM_SIGHD,__HAS_FROM,__HAS_MESSAGE_ID,__HAS_MSGID,__HAS_RCVD,__HAS_SUBJECT,__HAS_TO,__HAS_URI,__HDR_XAES_CAT,__HTML_IMG_ONLY,__JM_REACTOR_DATE,__KAM_MAILSPLOIT2,__KHOP_NO_FULL_NAME,__LAST_EXTERNAL_RELAY_NO_AUTH,__LAST_UNTRUSTED_RELAY_NO_AUTH,__LCL__ENV_AND_HDR_FROM_MATCH,__LOCAL_PP_NONPPURL,__LOWER_E(55),__MIME_BASE64,__MIME_HTML,__MIME_VERSION,__MISSING_REF,__MISSING_REPLY,__MSGID_OK_DIGITS,__NONEMPTY_BODY,__NOT_SPOOFED,__ONE_IMG,__PDS_FROM_NAME_TO_DOMAIN,__PNG_ATTACH_1,__RATWARE_0_TZ_DATE,__RBODY_MAILBOX,__SANE_MSGID,__SUBJ_NOT_SHORT,__TAG_EXISTS_BODY,__TAG_EXISTS_HEAD,__TAG_EXISTS_HTML,__TAG_EXISTS_META,__TAG_EXISTS_STYLE,__TOCC_EXISTS,__URI_MAILTO,__URI_WEBAPP 
(Total Subtest Hits: 172 / Deduplicated Total Hits: 62)


The rule will work because it's matching on __HDR_XAES_CAT, but i'm 
still wondering why the two X-Spam rules aren't hitting anything.




I believe header rules look at the whole line anyways with the exception 
of header lines that have known syntax.  That would NOT be X-Header 
checks.  I've had trouble there before.  Methinks you're pushing the 
envelope (and the envelope's giving you a paper cut).


I'd try:

1) Try appending your regex with /im .  The "m" has context outside of 
normal PERLs /g.  But preferably:

2) I'd get rid of delineation for those two Regexes, period.

X-Spam-Category =~ /(SPAM|PHISHING)/
X-AES-Category =~ /(SPAM|PHISHING)/

These are produced by something external with an obviously KNOWN 
pattern.  How many of those would you expect in a message?  That'd be 
another problem entirely.  SA syntax is PERLish-only and has does it's 
own internal sanity-checks and conversions.


$0.02,

-- Jared Hall

Matching on X-Spam headers doesn't get a hit

[Martin Flygenring]

Hi.

I'm trying to write a rule that matches on a mail that has the following 
headers:

X-Spam-Reasons: {'verdict': 'phishing',
 'spamcause': 
'gggruggvucftvghtrhhoucdtuddrgedvtddruddvgddugecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfkpffvgfftoffgfffktedpqfgfvfenuceurghilhhouhhtmecufedttdenucgorfhhihhshhhinhhgqdfkphfpvghtfihorhhkucdlfedttddmnecujfgurhephffvufffkfggtghisehrtdefvcdttddtnecuhfhrohhmpegtohhmphhlvghtvghtvghnuggvrhhsrdgtohhmucfuvghrvhgvrhcukffvuceouggrnhesshhhihhptghsuddrtghomheqnecuggftrfgrthhtvghrnhepleeiudeikeejffetgeetleeggfegteeghfdtveduvdekhedvlefgvedtueeiffejnecuffhomhgrihhnpeifvggsrdgrphhpnecukfhppeegtddrjeegrdduudefrddvgeeinecurfhhihhshhhinhhgkfhppfgvthifohhrkhepgedtrdejgedruddufedrvdegieenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepihhnvghtpefpohhnvgdpmhgrihhlfhhrohhmpegurghnsehshhhiphgtshdurdgtohhmpdhrtghpthhtohepmhgrthhthhgvfiestghomhhplhgvthgvthgvnhguvghrshdrtghomh',

 'elapsed': '4ms'}
X-AES-Category: SPAM
X-Spam-Category: PHISHING


This is the rules i have so far:
header  __HDR_XSPAM_CAT X-Spam-Category =~ /^(spam|phishing)$/i
header  __HDR_XSPAM_REASONS  X-Spam-Reasons =~ 
/['"](spam|phishing)['"]/i

header  __HDR_XAES_CAT  X-AES-Category =~ /^(spam|phishing)$/i
meta    SENDER_SPAM (__HDR_XSPAM_CAT || 
__HDR_XSPAM_REASONS || __HDR_XAES_CAT)
describe    SENDER_SPAM Message contains headers from sender 
indicating this is spam or phishing

scores  SENDER_SPAM 1


The only one that i can get working is the _HDR_XAES_CAT, both 
__HDR_XSPAM rules aren't hitting anything:

$ spamassassin -t -p ~/.spamassassin/mx teKbdz1W.txt -D 2>&1 | grep __HDR
Jul 22 17:00:53.480 [96] dbg: rules: ran header rule __HDR_XAES_CAT 
==> got hit: "SPAM"
Jul 22 17:00:54.439 [96] dbg: check: 
subtests=__ANY_IMAGE_ATTACH,__ANY_TEXT_ATTACH,__ANY_TEXT_ATTACH_DOC,__BODY_INVOICE_EN,__BODY_TEXT_LINE(3),__CT,__CTYPE_HAS_BOUNDARY,__CTYPE_MULTIPART_ANY,__DKIM_DEPENDABLE,__DKIM_EXISTS,__DOS_HAS_ANY_URI,__DOS_RCVD_MON,__DOS_RELAYED_EXT,__ENV_AND_HDR_FROM_MATCH,__E_LIKE_LETTER(55),__FORGED_RCVD_TRAIL,__FROM_ADMIN,__FROM_DOM_ADMIN,__HAS_ANY_EMAIL,__HAS_ANY_URI,__HAS_DATE,__HAS_DKIM_SIGHD,__HAS_FROM,__HAS_MESSAGE_ID,__HAS_MSGID,__HAS_RCVD,__HAS_SUBJECT,__HAS_TO,__HAS_URI,__HDR_XAES_CAT,__HTML_IMG_ONLY,__JM_REACTOR_DATE,__KAM_MAILSPLOIT2,__KHOP_NO_FULL_NAME,__LAST_EXTERNAL_RELAY_NO_AUTH,__LAST_UNTRUSTED_RELAY_NO_AUTH,__LCL__ENV_AND_HDR_FROM_MATCH,__LOCAL_PP_NONPPURL,__LOWER_E(55),__MIME_BASE64,__MIME_HTML,__MIME_VERSION,__MISSING_REF,__MISSING_REPLY,__MSGID_OK_DIGITS,__NONEMPTY_BODY,__NOT_SPOOFED,__ONE_IMG,__PDS_FROM_NAME_TO_DOMAIN,__PNG_ATTACH_1,__RATWARE_0_TZ_DATE,__RBODY_MAILBOX,__SANE_MSGID,__SUBJ_NOT_SHORT,__TAG_EXISTS_BODY,__TAG_EXISTS_HEAD,__TAG_EXISTS_HTML,__TAG_EXISTS_META,__TAG_EXISTS_STYLE,__TOCC_EXISTS,__URI_MAILTO,__URI_WEBAPP 
(Total Subtest Hits: 172 / Deduplicated Total Hits: 62)


The rule will work because it's matching on __HDR_XAES_CAT, but i'm 
still wondering why the two X-Spam rules aren't hitting anything.
Initial thought was that the X-Spam-Reasons header not being wrapped 
correctly was causing the issue, but since it's matching on the 
X-AES-Category header which comes after, and removing that 
X-Spam-Reasons header doesn't change anything for the X-Spam-Category 
header, so that doesn't seem to be the issue.


Is there a limitation to SpamAssassin so it doesn't accept looking for 
the two X-Spam-headers, or can you spot why this rule isn't matching?



Currently i'm testing it on:
SpamAssassin version 3.4.6
  running on Perl version 5.32.1
on a machine running Manjaro.


--
Martin Flygenring (maf)
Systems Engineer, One.com