Re: Where are your test definitions?

On 2024-06-14 at 17:33:22 UTC-0400 (Fri, 14 Jun 2024 23:33:22 +0200)
Thomas Barth via users <[email protected]>
is rumored to have said:

> Am 2024-06-14 21:20, schrieb Matus UHLAR - fantomas:
>>> grep -ri "FONT_INVIS_NORDNS" /var/lib/spamassassin/ | grep describe
>>> /var/lib/spamassassin/4.000000/updates_spamassassin_org/72_active.cf: 
>>> describe FONT_INVIS_NORDNS Invisible text + no rDNS
>>>
>>> In my case, I can say with certainty that the mail comes from a 
>>> business partner of a colleague :-)
>>
>> If you want to find out more, feed the mail to "spamassassin -D" and 
>> that should explain which text matched which rules.
>>
>> and as we told you already, your client should NOT play with small or 
>> semi-invisible text in mail. That's what spamers do.
>
> Cool, but now I ve more questions! :-)
>
> When the eMail arrived the score was 6.248. I repeat the testlist:
>
> BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1,
>  DKIM_VALID_EF=-0.1, DMARC_PASS=-0.001, FONT_INVIS_MSGID=2.497,
>  FONT_INVIS_NORDNS=1.544, HTML_FONT_TINY_NORDNS=1.514, 
> HTML_MESSAGE=0.001,
>  RDNS_NONE=0.793, RELAYCOUNTRY_BAD=2, SPF_HELO_NONE=0.001, 
> SPF_PASS=-0.001,
>  T_KAM_HTML_FONT_INVALID=0.01, T_SCC_BODY_TEXT_LINE=-0.01
>
> But when piping the eMail to spamassassin -D the score is 10.5! And 
> RDNS_NONE gets a 1.3!

It is very likely (almost certain...) that your shell account and your 
mail server have different SpamAssassin configurations. Per-user 
configurations are in ~/.spamassassin/user_prefs by default, while the 
settings used by SpamAssassin via whatever glue you are using to hook 
into your MTA really depends on how you do that. Per-user prefs can 
change scores or even scoresets (i.e. using net and bayes or not) so you 
need to figure out which prefs each checking method is using.

A single user also stands a strong chance of not having enough data 
learned into their own Bayes DB for it to be used, while a system-wide 
DB usually will. The above list has a (favorable) BAYES score, the one 
below has none

>
>  2.5 URIBL_DBL_SPAM         Contains a spam URL listed in the Spamhaus 
> DBL
>                             blocklist
>                             [URI: www.example.com]
>                             [URI: example.com]

That's a rule that is likely to hit on "aged" spam that it did not hit 
earlier, because it can take time for Spamhaus to list spammers like 
example.com... ( I assume you've redacted to protect the definitely 
guilty.)


>  0.0 SPF_HELO_NONE          SPF: HELO does not publish an SPF Record
>  0.1 DKIM_SIGNED            Message has a DKIM or DK signature, not 
> necessarily valid
>  0.1 DKIM_INVALID           DKIM or DK signature exists, but is not 
> valid
>  2.0 RELAYCOUNTRY_BAD       Relayed through spammy country at some 
> point
>  0.0 HTML_MESSAGE           BODY: Nachricht enth<E4>lt HTML
> -0.0 T_SCC_BODY_TEXT_LINE   No description available.
>  1.2 FONT_INVIS_NORDNS      Invisible text + no rDNS
>  1.3 RDNS_NONE              Delivered to internal network by a host 
> with no rDNS
>  0.0 T_KAM_HTML_FONT_INVALID Test for Invalidly Named or Formatted 
> Colors
>                             in HTML
>  2.5 FONT_INVIS_MSGID       Invisible text + suspicious message ID
>  0.0 HTML_FONT_TINY_NORDNS  Font too small to read, no rDNS
>  0.9 DMARC_NONE             DMARC none policy
>
> Let's just assume that the colleague is corresponding with a spammer

OR: discussing a spammer, with domain names.

> and the colleague knows nothing about it. I'm just interested to know 
> why the score is lower when the last mail arrived than in the current 
> test. Is it because a few hours have already passed and the mail is 
> rated differently in the DNS blocklists?

That's the URIBL_DBL_SPAM hit.

> Or could it be that something is still wrong with my configuration?

"Wrong" is such a judgy word...
You have variances. Your MTA checks in one way, your shell checks in 
another.

> However, I can see in the journal that every mail is checked against 
> blocklists, may be not completly? This difference is now irritating 
> me.


-- 
Bill Cole
[email protected] or [email protected]
(AKA @[email protected] and many *@billmail.scconsult.com 
addresses)
Not Currently Available For Hire