You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Philippe Chaintreuil via users <us...@spamassassin.apache.org> on 2022/12/25 17:27:39 UTC
4.0.0 dnsbl_subtests.t test failures
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
rules: unknown eval 'check_uridnsbl' for X_URIBL_Y_2F
rules: unknown eval 'check_uridnsbl' for X_URIBL_Y_2E
rules: unknown eval 'check_uridnsbl' for X_URIBL_N_255B
rules: unknown eval 'check_uridnsbl' for X_URIBL_Y_FFB
rules: unknown eval 'check_uridnsbl' for X_URIBL_Y_255A
rules: unknown eval 'check_uridnsbl' for X_URIBL_Y_2G
rules: unknown eval 'check_uridnsbl' for X_URIBL_N_0A
rules: unknown eval 'check_uridnsbl' for X_URIBL_Y_2A
rules: unknown eval 'check_uridnsbl' for X_URIBL_Y_2AZ2
rules: unknown eval 'check_uridnsbl' for X_URIBL_Y_3
rules: unknown eval 'check_uridnsbl' for X_URIBL_Y_2C
rules: unknown eval 'check_uridnsbl' for X_URIBL_Y_FFD
rules: unknown eval 'check_uridnsbl' for X_URIBL_Y_2B
rules: unknown eval 'check_uridnsbl' for X_URIBL_Y_ANY
rules: unknown eval 'check_uridnsbl' for X_URIBL_Y_FFA
rules: unknown eval 'check_uridnsbl' for X_URIBL_Y_FFC
rules: unknown eval 'check_uridnsbl' for X_URIBL_N_255A
rules: unknown eval 'check_uridnsbl' for X_URIBL_N_2G
rules: unknown eval 'check_uridnsbl' for X_URIBL_Y_255B
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
rules: unknown eval 'check_uridnsbl' for X_URIBL_Y_2F
rules: unknown eval 'check_uridnsbl' for X_URIBL_Y_2E
rules: unknown eval 'check_uridnsbl' for X_URIBL_N_255B
rules: unknown eval 'check_uridnsbl' for X_URIBL_Y_FFB
rules: unknown eval 'check_uridnsbl' for X_URIBL_Y_255A
rules: unknown eval 'check_uridnsbl' for X_URIBL_Y_2G
rules: unknown eval 'check_uridnsbl' for X_URIBL_N_0A
rules: unknown eval 'check_uridnsbl' for X_URIBL_Y_2A
rules: unknown eval 'check_uridnsbl' for X_URIBL_Y_2AZ2
rules: unknown eval 'check_uridnsbl' for X_URIBL_Y_3
rules: unknown eval 'check_uridnsbl' for X_URIBL_Y_2C
rules: unknown eval 'check_uridnsbl' for X_URIBL_Y_FFD
rules: unknown eval 'check_uridnsbl' for X_URIBL_Y_2B
rules: unknown eval 'check_uridnsbl' for X_URIBL_Y_ANY
rules: unknown eval 'check_uridnsbl' for X_URIBL_Y_FFA
rules: unknown eval 'check_uridnsbl' for X_URIBL_Y_FFC
rules: unknown eval 'check_uridnsbl' for X_URIBL_N_255A
rules: unknown eval 'check_uridnsbl' for X_URIBL_N_2G
rules: unknown eval 'check_uridnsbl' for X_URIBL_Y_255B
Not found: X_URIBL_Y_2A = X_URIBL_Y_2A at t/dnsbl_subtests.t
line 294.
# Failed test at t/SATest.pm line 926.
Not found: X_URIBL_Y_2B = X_URIBL_Y_2B at t/dnsbl_subtests.t
line 294.
# Failed test at t/SATest.pm line 926.
Not found: X_URIBL_Y_2C = X_URIBL_Y_2C at t/dnsbl_subtests.t
line 294.
# Failed test at t/SATest.pm line 926.
Not found: X_URIBL_Y_2D = X_URIBL_Y_2D at t/dnsbl_subtests.t
line 294.
# Failed test at t/SATest.pm line 926.
Not found: X_URIBL_Y_2E = X_URIBL_Y_2E at t/dnsbl_subtests.t
line 294.
# Failed test at t/SATest.pm line 926.
Not found: X_URIBL_Y_2F = X_URIBL_Y_2F at t/dnsbl_subtests.t
line 294.
# Failed test at t/SATest.pm line 926.
Not found: X_URIBL_Y_2G = X_URIBL_Y_2G at t/dnsbl_subtests.t
line 294.
# Failed test at t/SATest.pm line 926.
Not found: X_URIBL_Y_ANY = X_URIBL_Y_ANY at
t/dnsbl_subtests.t line 294.
# Failed test at t/SATest.pm line 926.
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
rules: unknown eval 'check_uridnsbl' for X_URIBL_Y_2F
rules: unknown eval 'check_uridnsbl' for X_URIBL_Y_2E
rules: unknown eval 'check_uridnsbl' for X_URIBL_N_255B
rules: unknown eval 'check_uridnsbl' for X_URIBL_Y_FFB
rules: unknown eval 'check_uridnsbl' for X_URIBL_Y_255A
rules: unknown eval 'check_uridnsbl' for X_URIBL_Y_2G
rules: unknown eval 'check_uridnsbl' for X_URIBL_N_0A
rules: unknown eval 'check_uridnsbl' for X_URIBL_Y_2A
rules: unknown eval 'check_uridnsbl' for X_URIBL_Y_2AZ2
rules: unknown eval 'check_uridnsbl' for X_URIBL_Y_3
rules: unknown eval 'check_uridnsbl' for X_URIBL_Y_2C
rules: unknown eval 'check_uridnsbl' for X_URIBL_Y_FFD
rules: unknown eval 'check_uridnsbl' for X_URIBL_Y_2B
rules: unknown eval 'check_uridnsbl' for X_URIBL_Y_ANY
rules: unknown eval 'check_uridnsbl' for X_URIBL_Y_FFA
rules: unknown eval 'check_uridnsbl' for X_URIBL_Y_FFC
rules: unknown eval 'check_uridnsbl' for X_URIBL_N_255A
rules: unknown eval 'check_uridnsbl' for X_URIBL_N_2G
... continues like this for a while ...
rules: unknown eval 'check_uridnsbl' for X_URIBL_N_2G
rules: unknown eval 'check_uridnsbl' for X_URIBL_Y_255B
Not found: X_URIBL_Y_255A = X_URIBL_Y_255A at
t/dnsbl_subtests.t line 294.
# Failed test at t/SATest.pm line 926.
Not found: X_URIBL_Y_255B = X_URIBL_Y_255B at
t/dnsbl_subtests.t line 294.
# Failed test at t/SATest.pm line 926.
Not found: X_URIBL_Y_2A = X_URIBL_Y_2A at t/dnsbl_subtests.t
line 294.
# Failed test at t/SATest.pm line 926.
Not found: X_URIBL_Y_2B = X_URIBL_Y_2B at t/dnsbl_subtests.t
line 294.
# Failed test at t/SATest.pm line 926.
Not found: X_URIBL_Y_2C = X_URIBL_Y_2C at t/dnsbl_subtests.t
line 294.
# Failed test at t/SATest.pm line 926.
Not found: X_URIBL_Y_2D = X_URIBL_Y_2D at t/dnsbl_subtests.t
line 294.
# Failed test at t/SATest.pm line 926.
Not found: X_URIBL_Y_2E = X_URIBL_Y_2E at t/dnsbl_subtests.t
line 294.
# Failed test at t/SATest.pm line 926.
Not found: X_URIBL_Y_2F = X_URIBL_Y_2F at t/dnsbl_subtests.t
line 294.
# Failed test at t/SATest.pm line 926.
Not found: X_URIBL_Y_2G = X_URIBL_Y_2G at t/dnsbl_subtests.t
line 294.
# Failed test at t/SATest.pm line 926.
Not found: X_URIBL_Y_FFA = X_URIBL_Y_FFA at
t/dnsbl_subtests.t line 294.
# Failed test at t/SATest.pm line 926.
Not found: X_URIBL_Y_FFB = X_URIBL_Y_FFB at
t/dnsbl_subtests.t line 294.
# Failed test at t/SATest.pm line 926.
Not found: X_URIBL_Y_FFC = X_URIBL_Y_FFC at
t/dnsbl_subtests.t line 294.
# Failed test at t/SATest.pm line 926.
# Looks like you failed 29 tests of 46.
t/dnsbl_subtests.t ................ Dubious, test returned 29 (wstat
7424, 0x1d00)
...
======================================================================
Re: 4.0.0 dnsbl_subtests.t test failures
Posted by Henrik K <he...@hege.li>.
On Mon, Dec 26, 2022 at 01:02:30PM +0200, Henrik K wrote:
> 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.
Additional thoughts for devs...
Not sure why all tests don't use the same method. Seems pointless to have
an external dependency to a public dnsbltest.spamassassin.org zone, when you
could just host it locally like dnsbl_subtests.t does. It would provide
consistent results and not require anyone to manually activate
run_net_tests for those tests.
Not volunteering to implement it though. ;-)
Re: 4.0.0 dnsbl_subtests.t test failures
Posted by Henrik K <he...@hege.li>.
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
Posted by Giovanni Bechis <gi...@paclan.it>.
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
Re: 4.0.0 dnsbl_subtests.t test failures
Posted by Benny Pedersen <me...@junc.eu>.
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
Posted by Bill Cole <sa...@billmail.scconsult.com>.
On 2022-12-26 at 13:57:20 UTC-0500 (Mon, 26 Dec 2022 13:57:20 -0500)
Philippe Chaintreuil via users
<sp...@parallaxshift.com>
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
bill@scconsult.com or billcole@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
Re: 4.0.0 dnsbl_subtests.t test failures
Posted by Michael Orlitzky <mi...@orlitzky.com>.
On Wed, 2022-12-28 at 16:44 +0200, Henrik K wrote:
>
> Doesn't look too good for Gentoo packaging though, if since 2009 v310.pre
> and newer have been full of all sorts of plugins loaded. It's like nobody
> actually cared since most of the stuff is useful. :-)
>
Nobody noticed until now, and now it's getting fixed. The intersection
of,
1. Gentoo users
2. People who run their own mail server
3. People who blindly run the default configuration on an important
network-facing daemon
is pretty small. And given that changing it is likely to generate a few
complaints, compared to the contented silence regarding the existing
behavior, you can maybe understand why no one has tried to proactively
fix it when it wasn't broken.
Re: 4.0.0 dnsbl_subtests.t test failures
Posted by Henrik K <he...@hege.li>.
On Wed, Dec 28, 2022 at 09:30:30AM -0500, Michael Orlitzky wrote:
> On Wed, 2022-12-28 at 16:20 +0200, Henrik K wrote:
> >
> > Common sense would ask that how is SPF harmful for the user? One would
> > think it would be actually desirable like any other network lookups, that
> > user might have accidentally left disabled? But sure, if this is the Gentoo
> > way, so be it. I had enough of 90's linux flashbacks trying it for the
> > first and last time today. :-)
> >
>
> Well, SPF wasn't nearly as reliable in 2005 as it is now, and it pulls
> in an extra dependency.
>
> Probably the best answer is that by having this ability, Gentoo
> attracts the sort of user who likes to disable such things to save disk
> space, shave off a few CPU cycles, or improve security. And then
> there's a feedback loop wherein most of our users want to retain the
> ability to control what gets installed/enabled.
Doesn't look too good for Gentoo packaging though, if since 2009 v310.pre
and newer have been full of all sorts of plugins loaded. It's like nobody
actually cared since most of the stuff is useful. :-)
Re: 4.0.0 dnsbl_subtests.t test failures
Posted by Michael Orlitzky <mi...@orlitzky.com>.
On Wed, 2022-12-28 at 16:20 +0200, Henrik K wrote:
>
> Common sense would ask that how is SPF harmful for the user? One would
> think it would be actually desirable like any other network lookups, that
> user might have accidentally left disabled? But sure, if this is the Gentoo
> way, so be it. I had enough of 90's linux flashbacks trying it for the
> first and last time today. :-)
>
Well, SPF wasn't nearly as reliable in 2005 as it is now, and it pulls
in an extra dependency.
Probably the best answer is that by having this ability, Gentoo
attracts the sort of user who likes to disable such things to save disk
space, shave off a few CPU cycles, or improve security. And then
there's a feedback loop wherein most of our users want to retain the
ability to control what gets installed/enabled.
Re: 4.0.0 dnsbl_subtests.t test failures
Posted by Henrik K <he...@hege.li>.
On Wed, Dec 28, 2022 at 09:10:13AM -0500, Michael Orlitzky wrote:
>
> Without disabling the plugin, how would that work? If the user happens
> to install Mail::SPF as a dependency of something else and if the
> plugin is *not* disabled, spamassassin will (surprise!) start using SPF
> against the user's wishes.
Common sense would ask that how is SPF harmful for the user? One would
think it would be actually desirable like any other network lookups, that
user might have accidentally left disabled? But sure, if this is the Gentoo
way, so be it. I had enough of 90's linux flashbacks trying it for the
first and last time today. :-)
Re: 4.0.0 dnsbl_subtests.t test failures
Posted by Michael Orlitzky <mi...@orlitzky.com>.
On Wed, 2022-12-28 at 15:38 +0200, Henrik K wrote:
>
> Disabling default plugins solves nothing, just creates a worse experience
> for user. Educating and guiding users to use DNS properly does not require
> this.
Gentoo builds everything from source and allows the user to
enable/disable some options for each package, called USE flags. In the
context of a C program, you might have USE=spf which would translate to
an additional dependency on libspf2 and passing
./configure --enable-spf
at build time to enable that feature.
These map less well to scripting languages where features are often
enabled at runtime based on the existence of some optional package. In
2005, we had a flag for USE=spf in spamassassin that was supposed to
control whether or not spamassassin used SPF.
Without disabling the plugin, how would that work? If the user happens
to install Mail::SPF as a dependency of something else and if the
plugin is *not* disabled, spamassassin will (surprise!) start using SPF
against the user's wishes.
There's no reason for it today because there's no USE=spf flag for
spamassassin, and it wasn't implemented very well back in 2005 (only
certain plugins should have been disabled, and only conditionally). But
the idea isn't as crazy as it first sounds.
Re: 4.0.0 dnsbl_subtests.t test failures
Posted by Henrik K <he...@hege.li>.
On Wed, Dec 28, 2022 at 02:29:03PM +0100, Benny Pedersen wrote:
>
> i will like to see default all plugins disabled, and a install howto enabled
> needed plugin as needed, there is not anypoint on enabled all, and all it
> gets is dns refused .....
>
> or some *_BLCOKED like apache infra cant solve
Disabling default plugins solves nothing, just creates a worse experience
for user. Educating and guiding users to use DNS properly does not require
this.
Re: 4.0.0 dnsbl_subtests.t test failures
Posted by "Kevin A. McGrail" <km...@apache.org>.
Howdy,
> if test useflag is in game, all plugins should be disabled, only check
> plugin should be enabled, while testing .t rules, this test is only
> for developpers and repo maintainers, not end users on gentoo
I'd bring that up on the Gentoo list.
> i will like to see default all plugins disabled, and a install howto
> enabled needed plugin as needed, there is not anypoint on enabled all,
> and all it gets is dns refused .....
IMO, Apache SpamAssassin is a framework that needs additions, tuning,
data feeds, and configuration. I do not speak for the project in this
regard but I do not view it as a drop-in solution. I encourage you to
write a wiki article about the plugins you recommend and why. You can
even document a quick sed script quoted in this thread can disable all
the plugins in .pre files. Et voila.
> or some *_BLCOKED like apache infra cant solve
"Infra can't solve" seems more than a bit disingenuous. Did you ever
report the problem to Infrastructure as I instructed you? Seems like a
better use of all our time instead emailing the list complaining about a
problem with a system we don't control.
Regards,
KAM
--
Kevin A. McGrail
KMcGrail@Apache.org
Member, Apache Software Foundation
Chair Emeritus Apache SpamAssassin Project
https://www.linkedin.com/in/kmcgrail - 703.798.0171
Re: 4.0.0 dnsbl_subtests.t test failures
Posted by Benny Pedersen <me...@junc.eu>.
Kevin A. McGrail skrev den 2022-12-28 14:22:
> +1 thanks for bringing this up and bridging the fix!
>
> On 12/28/2022 8:20 AM, Philippe Chaintreuil via users wrote:
>> I'm going to make a Gentoo Pull Request to try to remove the init.pre
>> blanket disable, because at this point we do install most of those
>> dependencies by default. Failing that I'll get the init.pre
>> modifications to after tests run.
if test useflag is in game, all plugins should be disabled, only check
plugin should be enabled, while testing .t rules, this test is only for
developpers and repo maintainers, not end users on gentoo
i will like to see default all plugins disabled, and a install howto
enabled needed plugin as needed, there is not anypoint on enabled all,
and all it gets is dns refused .....
or some *_BLCOKED like apache infra cant solve
Re: 4.0.0 dnsbl_subtests.t test failures
Posted by "Kevin A. McGrail" <km...@apache.org>.
+1 thanks for bringing this up and bridging the fix!
On 12/28/2022 8:20 AM, Philippe Chaintreuil via users wrote:
> I'm going to make a Gentoo Pull Request to try to remove the init.pre
> blanket disable, because at this point we do install most of those
> dependencies by default. Failing that I'll get the init.pre
> modifications to after tests run.
--
Kevin A. McGrail
KMcGrail@Apache.org
Member, Apache Software Foundation
Chair Emeritus Apache SpamAssassin Project
https://www.linkedin.com/in/kmcgrail - 703.798.0171
Re: 4.0.0 dnsbl_subtests.t test failures
Posted by Matus UHLAR - fantomas <uh...@fantomas.sk>.
>On Wed, Dec 28, 2022 at 08:20:04AM -0500, Philippe Chaintreuil via users wrote:
>> So there's desire that if a user doesn't want Mail::SPF installed, and
>> SpamAssassin doesn't REQUIRE it (which it doesn't), it shouldn't be force
>> installed. But for SpamAssassin to work as installed, that plugin can't be
>> enabled by default.
On 28.12.22 15:36, Henrik K wrote:
>Even if Mail::SPF is not installed, it doesn't prevents you from loading the
>SPF plugin, it just automatically disables itself.
I think it doesn't even disable itself, just SPF lookups, but it can use
results of Authentication-Results: header added by e.g. local milter.
--
Matus UHLAR - fantomas, uhlar@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Depression is merely anger without enthusiasm.
Re: 4.0.0 dnsbl_subtests.t test failures
Posted by Henrik K <he...@hege.li>.
On Wed, Dec 28, 2022 at 08:20:04AM -0500, Philippe Chaintreuil via users wrote:
>
> So there's desire that if a user doesn't want Mail::SPF installed, and
> SpamAssassin doesn't REQUIRE it (which it doesn't), it shouldn't be force
> installed. But for SpamAssassin to work as installed, that plugin can't be
> enabled by default.
Even if Mail::SPF is not installed, it doesn't prevents you from loading the
SPF plugin, it just automatically disables itself. This should be the
behavior for all the other default plugins too.
> I went back through Gentoo's history and it's been that way since 2005.
Common theme with SA. :-D
> There used to be a post-install warning that you'd need to choose which
> plugins you wanted enabled, but it got stripped out at some point. There is
> a section in the wiki that indicates you should go through the .pre files to
> enable/disable plugins.
> https://wiki.gentoo.org/wiki/SpamAssassin#Configuration
If default plugins aren't default as provided by SA for the rest of the
world, this should by explicitly implied in the wiki. Someone could simply
come from other standard installs and assume URIDNSBL etc are loaded, as it
would make no sense for it to be disabled by default.
The default plugin set is intended for scanning to work well out of the box,
assuming of course that user installed all required Perl modules.
Re: 4.0.0 dnsbl_subtests.t test failures
Posted by Philippe Chaintreuil via users <us...@spamassassin.apache.org>.
TL;DR:
I'm going to try get the init.pre disables removed in Gentoo, failing
that I'm going to move it to /etc/spamassassin/ modifications instead of
changing the files in rules/.
> I believe Philippe is the package maintainer, so it's up to him I
> guess. 😄
Disclaimer:
I'm just a volunteer who chips in on the package. I don't even have
commit privileges.
> It's completely baffling why and how Gentoo does this.
It's because Gentoo's ethos is user-choice and control over what's
installed.
So there's desire that if a user doesn't want Mail::SPF installed, and
SpamAssassin doesn't REQUIRE it (which it doesn't), it shouldn't be
force installed. But for SpamAssassin to work as installed, that plugin
can't be enabled by default.
If a user wants it, they can enable the plugin in the .pre and install
the stated required dependencies. The user gives up some
"install-it-just-works" for energy spent on configuration in order to
gain that control.
That said, in recent years, at least for SpamAssassin, we've been
installing more and more of the commonly used dependencies.
> It only disables loadplugins in init.pre, and not other *.pre files. This
> is already a bug in itself by not being consistent.
I agree that it's odd that only init.pre gets the blanket disable -- why
when new v3xx.pre files were added this didn't get applied to them as well.
I went back through Gentoo's history and it's been that way since 2005.
https://github.com/gentoo/gentoo-gitmig-20150809-draft/commit/5ab3758535e49f95644cbf2d621b7d67bd7ccdfe
My guess is at the time, Users were probably getting errors about
missing dependencies. I'd venture that init.pre was the only plugin
config that had non-required external dependencies
(Mail::SpamAssassin::Plugin::RelayCountry, geoip.cf to be edited,
Mail::SPF), so it was the only one modified.
There used to be a post-install warning that you'd need to choose which
plugins you wanted enabled, but it got stripped out at some point.
There is a section in the wiki that indicates you should go through the
.pre files to enable/disable plugins.
https://wiki.gentoo.org/wiki/SpamAssassin#Configuration
I'm going to make a Gentoo Pull Request to try to remove the init.pre
blanket disable, because at this point we do install most of those
dependencies by default. Failing that I'll get the init.pre
modifications to after tests run.
Re: 4.0.0 dnsbl_subtests.t test failures
Posted by Henrik K <he...@hege.li>.
I believe Philippe is the package maintainer, so it's up to him I guess. :-)
On Wed, Dec 28, 2022 at 06:35:07AM -0500, Kevin A. McGrail wrote:
> +1 and over and above by Henrik to install the distro for testing.
>
> Our project cannot be responsible for the decisions of the distribution package
> maintainers. This is definitely one that is not the right decision.
>
> Do we have a contact at Gentoo?
>
> Regards, KAM
>
> On Wed, Dec 28, 2022, 04:38 Henrik K <[1...@hege.li> wrote:
>
> On Mon, Dec 26, 2022 at 01:57:20PM -0500, Philippe Chaintreuil via users
> wrote:
> > 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.
>
> As mentioned on bug:
> [2]https://bz.apache.org/SpamAssassin/show_bug.cgi?id=8095
>
> It's completely baffling why and how Gentoo does this. It only disables
> loadplugins in init.pre, and not other *.pre files. This is already a bug
> in itself by not being consistent.
>
> I even installed Gentoo to check what the fuss is about. There is no
> mention from installer or wiki that users need to go enable plugins in
> /etc/mail/spamassassin/*.pre files, which are almost universally used by
> default on every other distribution.
>
> The workaround for Gentoo installer is NOT TO MODIFY SUCH SOURCE FILES
> DIRECTLY. If you want to confuse users with non-standard defaults, pretty
> sure you can figure out how to modify the files without touching the
> originals, which the test system makes use of. :-)
>
>
>
> References:
>
> [1] mailto:hege@hege.li
> [2] https://bz.apache.org/SpamAssassin/show_bug.cgi?id=8095
Re: 4.0.0 dnsbl_subtests.t test failures
Posted by "Kevin A. McGrail" <km...@apache.org>.
+1 and over and above by Henrik to install the distro for testing.
Our project cannot be responsible for the decisions of the distribution
package maintainers. This is definitely one that is not the right decision.
Do we have a contact at Gentoo?
Regards, KAM
On Wed, Dec 28, 2022, 04:38 Henrik K <he...@hege.li> wrote:
> On Mon, Dec 26, 2022 at 01:57:20PM -0500, Philippe Chaintreuil via users
> wrote:
> > 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.
>
> As mentioned on bug:
> https://bz.apache.org/SpamAssassin/show_bug.cgi?id=8095
>
> It's completely baffling why and how Gentoo does this. It only disables
> loadplugins in init.pre, and not other *.pre files. This is already a bug
> in itself by not being consistent.
>
> I even installed Gentoo to check what the fuss is about. There is no
> mention from installer or wiki that users need to go enable plugins in
> /etc/mail/spamassassin/*.pre files, which are almost universally used by
> default on every other distribution.
>
> The workaround for Gentoo installer is NOT TO MODIFY SUCH SOURCE FILES
> DIRECTLY. If you want to confuse users with non-standard defaults, pretty
> sure you can figure out how to modify the files without touching the
> originals, which the test system makes use of. :-)
>
>
Re: 4.0.0 dnsbl_subtests.t test failures
Posted by Henrik K <he...@hege.li>.
On Mon, Dec 26, 2022 at 01:57:20PM -0500, Philippe Chaintreuil via users wrote:
> 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.
As mentioned on bug:
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=8095
It's completely baffling why and how Gentoo does this. It only disables
loadplugins in init.pre, and not other *.pre files. This is already a bug
in itself by not being consistent.
I even installed Gentoo to check what the fuss is about. There is no
mention from installer or wiki that users need to go enable plugins in
/etc/mail/spamassassin/*.pre files, which are almost universally used by
default on every other distribution.
The workaround for Gentoo installer is NOT TO MODIFY SUCH SOURCE FILES
DIRECTLY. If you want to confuse users with non-standard defaults, pretty
sure you can figure out how to modify the files without touching the
originals, which the test system makes use of. :-)
Re: 4.0.0 dnsbl_subtests.t test failures
Posted by Philippe Chaintreuil via users <us...@spamassassin.apache.org>.
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
Posted by Philippe Chaintreuil via users <us...@spamassassin.apache.org>.
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
Posted by Sidney Markowitz <si...@sidney.com>.
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.
rules/init.pre contains a second loadplugin line, for spf. If the entire
file is not being loaded then if you enable net tests then the t/spf.t
and t/spf_welcome.t tests would fail too because the spf plugin will be
missing, as well as t/uribl.t failing because URIDNSBL is missing.
I guess you should see if rules/init.pre is somehow not there.