Re: DNSWL_HI testing wrong Received header?

2022-12-26 Thread Benny Pedersen

John Stimson via users skrev den 2022-12-26 21:44:


Here's an example header:


X-Originating-Ip: [40.92.91.45]

this header is expanded in spamassassin and sure currently gives 
https://dnswl.org/s/?s=1357


i consider trust here not good to use forged header info to whitelist 
ips, when this ip is not in recieved header


X-Originating-Ip should not be used for whitelists, only for blacklist 
rbl, even on only blacklist its unsafe to use, rules maintainers can 
remove it, now that spamassassin 4.0.0 is out :)


read "perldoc Mail::SpamAssassin::Conf" to see how this header is 
included, and remove it


Re: DNSWL_HI testing wrong Received header?

2022-12-26 Thread Benny Pedersen

John Stimson via users skrev den 2022-12-26 21:44:


My second question is where to report an SMTP server that passes SPF,
but is passing spam with forged Received headers.

Here's an example header:


Received: from aznavrchol.cz (unknown [85.204.116.245])
by idsfa.net (Postfix) with ESMTP id 2EF948C00FC
for ; Sun, 22 May 2022 20:12:15 -0700 (PDT)

this is not listed in dnswl.org

https://multirbl.valli.org/lookup/85.204.116.245.html

have you setup trusted_networks, internal_networks, msa_networks correct 
in spamassassin ?


if you can confirm it uses other headers for dnswl.org then remove this 
headers before spamassassin see it, thats the forged header imho X-* and 
friends there :=)




DNSWL_HI testing wrong Received header?

2022-12-26 Thread John Stimson via users

Hello,

I have lately seen an increase in the number of spam messages passing 
spamassassin.  Checking the X-Spam-Status header, I see that the common 
reason they are all passing is that they hit the DNSWL_HI test to get a 
-5 adjustment to their spam score. However, when I check the IP address 
of the server that my domain received the message directly from, that IP 
address is not in the DNSWL high trust database.  There are forged 
Received headers lower down, for Gmail or Hotmail servers, and I suspect 
that those are the IPs being checked in the DNSWL_HI test. Otherwise I 
don't know why DNSWL_HI is being triggered.


My second question is where to report an SMTP server that passes SPF, 
but is passing spam with forged Received headers.


Here's an example header:

Return-Path: <>
X-Original-To:j...@idsfa.net
Delivered-To:j...@idsfa.net
Received: from localhost (localhost [127.0.0.1])
by idsfa.net (Postfix) with ESMTP id 29F168C0136
for; Sun, 22 May 2022 20:12:17 -0700 (PDT)
X-Spam-Flag: NO
X-Spam-Score: 4.319
X-Spam-Level: 
X-Spam-Status: No, score=4.319 tagged_above=-5 required=6.31
tests=[ACT_NOW_CAPS=0.1, BAYES_99=3.5, BAYES_999=0.2,
DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_FONT_SIZE_LARGE=0.001,
HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.377, MIME_HTML_ONLY=0.1,
PYZOR_CHECK=1.392, RCVD_IN_BL_SPAMCOP_NET=1.347, RCVD_IN_DNSWL_HI=-5,
RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_VALIDITY_RPBL=1.31, RDNS_NONE=0.793,
SPF_HELO_PASS=-0.001, T_DATE_IN_FUTURE_96_Q=0.01,
T_SCC_BODY_TEXT_LINE=-0.01] autolearn=no autolearn_force=no
Authentication-Results: harlie.idsfa.net (amavisd-new);
dkim=fail (2048-bit key) reason="fail (message has been altered)"
header.d=hotmail.com
Received: from idsfa.net ([127.0.0.1])
by localhost (harlie.idsfa.net [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id GXmcEm9KlHEF for;
Sun, 22 May 2022 20:12:16 -0700 (PDT)
Received-SPF: Pass (helo) identity=helo; client-ip=85.204.116.245; helo=aznavrchol.cz; 
envelope-from=<>; receiver=
Authentication-Results: idsfa.net;
dkim=fail reason="signature verification failed" (2048-bit key; unprotected) 
header.d=hotmail.comheader.i=@hotmail.com  header.b="JRELNzNe";
dkim-atps=neutral
Received: from aznavrchol.cz (unknown [85.204.116.245])
by idsfa.net (Postfix) with ESMTP id 2EF948C00FC
for; Sun, 22 May 2022 20:12:15 -0700 (PDT)
Received: from 10.196.243.97
 by atlas113.aol.mail.bf1.yahoo.com with HTTPS; Mon, 16 May 2033 09:37:50 +
X-Originating-Ip: [40.92.91.45]
Received-SPF: pass (domain of hotmail.com designates 40.92.91.45 as permitted 
sender)
Authentication-Results: atlas113.aol.mail.bf1.yahoo.com;
 dkim=passheader.i=@hotmail.com  header.s=selector1;
 spf=pass smtp.mailfrom=hotmail.com;
 dmarc=pass(p=NONE) header.from=hotmail.com;
X-Apparently-To:j...@idsfa.net; Mon, 16 May 2033 09:37:50 +


Re: 4.0.0 dnsbl_subtests.t test failures

2022-12-26 Thread Benny Pedersen

Bill Cole skrev den 2022-12-26 20:37:

Gentoo disables all plugins in init.pre so users have to choose which 
plugins to use and do any required configuration after install.


good to see its on the way, but Bill is not a gentoo user imho


That should break MANY tests, and reflects an error in judgment by the
packager. With all plugins disabled, SA is not even minimally
functional.


no gentoo have a test use flag that is disabled by default, unless end 
users have test in useflag should not make diable all plugins default 
break anything


this is the same bug that redhat users compile rules into rpms for not 
using sa-update at all


fair ?


Re: 4.0.0 dnsbl_subtests.t test failures

2022-12-26 Thread Bill Cole

On 2022-12-26 at 13:57:20 UTC-0500 (Mon, 26 Dec 2022 13:57:20 -0500)
Philippe Chaintreuil via users 


is rumored to have said:


On 12/25/2022 4:38 PM, Sidney Markowitz wrote:
I can get exactly that set of error messages by commenting out the 
loadplugin for URIDNSBL in rules/init.pre or deleting the file 
rules/init.pre completely, and running make test with the default 
setting of run_net_tests=n in t/config.dist. If I change it to 
run_net_tests=y then the test t/uribl.t also fails where it tries to 
use check_uridnsbl


Gentoo disables all plugins in init.pre so users have to choose which 
plugins to use and do any required configuration after install.


That should break MANY tests, and reflects an error in judgment by the 
packager. With all plugins disabled, SA is not even minimally 
functional.




--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire


Re: 4.0.0 dnsbl_subtests.t test failures

2022-12-26 Thread Philippe Chaintreuil via users

On 12/26/2022 1:57 PM, Philippe Chaintreuil via users wrote:
Anyway to check at the top of the dnsbl_subtests.t if 
Mail::SpamAssassin::Plugin::URIDNSBL has been loaded or not to have it 
punt?


Just noticed how spf.t does this.


use constant HAS_URIDNSBL => eval {
  require Mail::SpamAssassin::Plugin::URIDNSBL ;
};


plan skip_all => "Need Mail::SpamAssassin::Plugin::URIDNSBL in init.pre" 
unless HAS_URIDNSBL;



Seem sane?


Re: 4.0.0 dnsbl_subtests.t test failures

2022-12-26 Thread Philippe Chaintreuil via users

On 12/25/2022 4:38 PM, Sidney Markowitz wrote:
I can get exactly that set of error messages by commenting out the 
loadplugin for URIDNSBL in rules/init.pre or deleting the file 
rules/init.pre completely, and running make test with the default 
setting of run_net_tests=n in t/config.dist. If I change it to 
run_net_tests=y then the test t/uribl.t also fails where it tries to use 
check_uridnsbl


Gentoo disables all plugins in init.pre so users have to choose which 
plugins to use and do any required configuration after install.


Anyway to check at the top of the dnsbl_subtests.t if 
Mail::SpamAssassin::Plugin::URIDNSBL has been loaded or not to have it punt?



rules/init.pre contains a second loadplugin line, for spf.


This doesn't fail because it has a "Net tests disabled" test at the top.




Re: 4.0.0 dnsbl_subtests.t test failures

2022-12-26 Thread Henrik K
On Mon, Dec 26, 2022 at 11:54:12AM +0100, Giovanni Bechis wrote:
>
> dnsbl_subtests.t tests runs even with run_net_tests=n (fixed few minutes
> ago in trunk)

The fix is not needed.

dnsbl_subtests.t starts a _local_ nameserver and never sends queries to
public internet.

The intention of run_net_tests=n is to prevent test scripts from failing if
you don't have a internet connection.  This test does not require a working
connection.



Re: 4.0.0 dnsbl_subtests.t test failures

2022-12-26 Thread Giovanni Bechis
On Mon, Dec 26, 2022 at 10:38:07AM +1300, Sidney Markowitz wrote:
> Philippe Chaintreuil via users wrote on 26/12/22 6:27 am:
> > I'm getting test failures for the dnsbl_subtests.t.  Figured I'd check
> > here before filing a bug.
> > 
> > I'm running Spam Assassin 4.0.0 on Gentoo Linux.  Perl 5.36.0.
> > 
> > Test output:
> > 
> > ==
> >  ...
> > t/dnsbl_subtests.t  1/46 rules: unknown eval
> > 'check_uridnsbl' for X_URIBL_N_3
> > rules: unknown eval 'check_uridnsbl' for X_URIBL_Y_2D
> > rules: unknown eval 'check_uridnsbl' for X_URIBL_N_0B
> 
> I haven't tested on gentoo, but I have tested on different platforms 
> with perl 5.36.0.
> 
> I can get exactly that set of error messages by commenting out the 
> loadplugin for URIDNSBL in rules/init.pre or deleting the file 
> rules/init.pre completely, and running make test with the default 
> setting of run_net_tests=n in t/config.dist. If I change it to 
> run_net_tests=y then the test t/uribl.t also fails where it tries to use 
> check_uridnsbl
> 
> None of the other tests use check_uridnsbl so they don't generate 
> errors. t/spamd_allow_user_rules.t references check_uridnsbl but it is 
> checking something with rule parsing and never tries to run it so it 
> doesn't fail.
> 
dnsbl_subtests.t tests runs even with run_net_tests=n (fixed few minutes
ago in trunk), the "unknown eval" error is unrelated to this bug anyway,
I think in this case the user fails to load init.pre correctly in his
setup.
 Giovanni


signature.asc
Description: PGP signature