Ubuntu
libmail-dmarc-perl package

[MIR] libmail-dmarc-perl

Bug #2023971 reported by Bryce Harrington on 2023-06-15

This bug affects 2 people

Affects		Status	Importance	Assigned to	Milestone
	libmail-dmarc-perl (Ubuntu)	Incomplete	High	Miriam España Acebal

Bug Description

[NEW description DRAFT- WIP: updated the 11 packages that need to be promoted only (yes), revamping the other sections (wip)]

Please promote libmail-dmarc-perl and its universe dependencies (recursively) to main. According to `check-mir` (+ recursive searching) this would need ~44 packages to be promoted (as runtime binary dependencies, see original description if needed).

However, libmail-dmarc-perl is only used by the spamassassin package, and spamassasin only uses the validation feaure of DMARC, so we can narrow the necessary binaries dependencies to be promoted too. Those packages are the following ones (11):

The rest would be moved to Suggested dependencies.

[Availability]
The package libmail-dmarc-perl and all of its dependencies already exist in Ubuntu universe, and all build ok for the target architectures.

[Rationale]
tldr; DMARC support in SpamAssassin is important for stronger spam filtering.

Spam email is an ever-present and ever-evolving presence in our online lives, and SpamAssassin is a key tool for end users and service providers to identify likely spam for filtering. SpamAssassin 4.0, introduced in Ubuntu "lunar" 22.10, introduced a number of major new features including three new plugins, the most significant of which is the DMARC policy checker.

DMARC (or "Domain-based Message Authentication, Reporting & Conformance") is a new convention for email service providers to communicate to email recipient programs about how to handle authentication failures. It builds on prior protocols (namely, SPF and DKIM) to address their limitations. Essentially, DMARC protects against direct domain spoofing, such that when an email purports to be from a given domain (say, @gmail.com or @irs.gov) but fails proper authentication using the authentication methods published by that domain, it tells the email receiver whether to reject the email as spam, quarantine it for evaluation, or something else. DMARC also establishes a way for the email receiver to give feedback back to the sender about emails that failed to pass this check.

libmail-dmarc-perl contains the official Perl implementation of DMARC support. SpamAssassin is the primary user of this package

❯ apt-cache rdepends libmail-dmarc-perl
libmail-dmarc-perl
Reverse Depends:
spamassassin

and requires it in order to perform this DMARC evaluation: Spamassasin dmarc plugin [1] only uses the MAIL::DMARC::PurePerl module [2] and, inside it, the validate function in particular [3]. However, is true that it also could use the save_aggregate function if the dmarc_save_reports variable is set through mail-dmarc.ini to 1 (defaults is 0 [4], and also in the ini file [5]). That function will need the Mail::DMARC::Report::Store module and the Mail::DMARC::Report::URI module.

libmail-dmarc-perl is a relatively new source package that was proposed for lunar but deleted on 2023-05-01 due to build/autopkgtest issues and later re-introduced to mantic once those issues were resolved, on 2023-06-13.

[1] (https://git.launchpad.net/ubuntu/+source/spamassassin/tree/lib/Mail/SpamAssassin/Plugin/DMARC.pm)
[2] (https://git.launchpad.net/ubuntu/+source/spamassassin/tree/lib/Mail/SpamAssassin/Plugin/DMARC.pm#n242)
[3] (https://git.launchpad.net/ubuntu/+source/spamassassin/tree/lib/Mail/SpamAssassin/Plugin/DMARC.pm#n322)
[4] (https://git.launchpad.net/ubuntu/+source/spamassassin/tree/lib/Mail/SpamAssassin/Plugin/DMARC.pm#n111)
[5] (https://git.launchpad.net/ubuntu/+source/libmail-dmarc-perl/tree/share/mail-dmarc.ini#n21)

[Security]
"libmail-dmarc-perl" turns up zero CVE or other records in mitre.org, openwall, ubuntu.com/security, or security-tracker.debian.org. Broadening the search to "spamassassin dmarc" shows only a single issue within the past few years, CVE-2022-3620, which appears to be more of an issue in exim4 specifically, and has been deemed not relevant to the exim4 package shipped in Ubuntu (See https://ubuntu.com/security/CVE-2022-3620).

I've not individually checked the specific perl modules involved here, but from a detailed review of the package histories I did not spot any security activity. Presumably this indicates that the level of security support for the lot is going to be quite low or negligible. Given that many of these modules are core Perl components, I would expect they receive adequate security attention from their upstream maintainers, and given the low rate of change of the packages the security risk from them is low.

In general Perl libraries do not install executables to /sbin or /usr/sbin, and by definition do not install services, do not open privileged ports, or modify security-sensitive software. Again, I've not individually checked each module to verify, but such situations would seem exceptional.

[Quality assurance - function/usage]
I've verified libmail-dmarc-perl installs with its required installation dependencies.

I've verified in a mantic LXC container that its required build dependencies get installed, and both debuild -S and debuild pass without error.

I've run libmail-dmarc-perl's autopkgtest locally in LXC, verified it invokes the upstream testsuite, and all test cases pass without issue.

I've not verified the build/autopkgtest of all the component dependency perl modules, however Perl modules tend to receive ample attention via proposed-migration's update-excuses page, and presently none of the perl modules in this MIR are listed as having issues.

Integration with spamassassin has been tested by co-installing it, updating the configuration, running sa-compile, and checking for errors. Behavioral performance was checked by running:

$ spamassassin --debug < /home/bryce/pkg/Spamassassin/spam.mbox

I unfortunately was not able to verify a successful DMARC processing of emails, however the presence of the module and enabling configuration statements did not cause any errors or failures.

[Quality assurance - maintenance]
I've checked each Perl module's package history. Most have been around for many, many years and most have zero bugs in Ubuntu, others have a small number that have been closed, and a few have a small number of open bugs but none that appear concerning. I only spot checked bug reports upstream and in Debian, but bug activity there was similarly light. I didn't spot any open bugs that looked important or worth highlighting; see below for the per-package bug analysis.

[Quality assurance - testing]
I ran libmail-dmarc-perl's autopkgtest, which invokes the upstream testsuite. No errors were produced by this. I did not review or run autopkgtests for libmail-dmarc-perl's dependencies however I did verify none are listed on mantic's update-excuses page for proposed-migration so there are at least no known issues.

Nearly all these perl modules have been around for many years, so their testing status and behavior is well established.

[Quality assurance - packaging]
Debian covers the packaging needs adequately for these packages. Most of these packages receive upstream releases only infrequently, and Debian seems to be on top of keeping them up to date. An in-depth study of watch files, lintian, etc. was not performed but is not expected to be noteworthy, regardless of state.

All packages were verified as not relying on obsolete or demoted packages; see the per-package analysis below for detailed discussion.

[UI Standards]
Application is not end-user facing (does not need translation)

[Dependencies]
Unfortunately, since it's a new package, libmail-dmarc-perl resides in universe. Since spamassassin lives in main, this creates a component mismatch. Compounding the issue, libmail-dmarc-perl itself depends on other source packages that also are only available via universe.

The MIR process (https://github.com/canonical/ubuntu-mir) indicates that Build dependencies can be in universe, so we'll focus just on the binary dependencies (the build dependencies get rather involved.)

[Standards Compliance]
These packages correctly follow FHS and Debian Policy

[Maintenance/Owner]
libmail-dmarc-perl and its dependencies are maintained by the Debian project, and acceptably maintained by them and the Perl project upstream. In Ubuntu, these packages will be added to the ubuntu-server team's list once this MIR is accepted, if they're not covered already by other teams (the Foundations team has covered maintenance at points in the past).

This package does not use vendered code, is not rust-based, and does not have build issues currently identified.

See original description

Tags:

Bryce Harrington (bryce) on 2023-06-30

description:	updated
Changed in libmail-dmarc-perl (Ubuntu):
status:	Incomplete → New

Revision history for this message

Christian Ehrhardt  (paelzer) wrote on 2023-07-04 (last edit on 2023-07-04):

Actually, this shouldn't be tasks nowadays. Individual bugs would be better.
Since they are so similar all the meta-discussion can happen here.
And a link farm to reach the others is useful, see how Lucas has done pcs.

So the others can - for now - be shallow forks for tooling to work well.

Miriam España Acebal (mirespace) on 2023-07-06

Changed in libmail-dmarc-perl (Ubuntu):
assignee:	nobody → Miriam España Acebal (mirespace)

Revision history for this message

Christian Ehrhardt  (paelzer) wrote on 2023-07-06:

Incomplete as Miriam will prep a bit more for all the dependencies

Changed in libmail-dmarc-perl (Ubuntu):
status:	New → Incomplete

Miriam España Acebal (mirespace) on 2023-08-02

description:

updated

Miriam España Acebal (mirespace) on 2023-08-08

description:

updated

Miriam España Acebal (mirespace) on 2023-08-09

description:

updated

Miriam España Acebal (mirespace) on 2023-08-10

description:

updated

Miriam España Acebal (mirespace) on 2023-08-10

description:

updated

Miriam España Acebal (mirespace) on 2023-08-10

description:

updated

Miriam España Acebal (mirespace) on 2023-08-11

description:

updated

Revision history for this message

Christian Ehrhardt  (paelzer) wrote on 2023-08-16:

Miriam will continue spreading out the prep work by Bryce to create more individual bugs to process.
But for now the initial 6 have been opened and are ready for review (to not stall getting this started further).

We can see on those if our hope for "most should be trivial and quick perl cases" is true.

Miriam España Acebal (mirespace) on 2023-08-16

description:

updated

Miriam España Acebal (mirespace) on 2023-08-16

description:

updated

Miriam España Acebal (mirespace) on 2023-09-01

description:

updated

Miriam España Acebal (mirespace) on 2023-09-26

description:

updated

Miriam España Acebal (mirespace) on 2023-09-26

description:

updated

Miriam España Acebal (mirespace) on 2023-09-26

description:

updated

Christian Ehrhardt  (paelzer) on 2023-09-28

description:

updated

Miriam España Acebal (mirespace) on 2023-09-28

description:

updated

Revision history for this message

Christian Ehrhardt  (paelzer) wrote on 2023-09-28:

AFAICS libtest-file-sharedir-perl is only used in tests:

root@m:~/libmail-dmarc-perl-1.20230215# grep -Hrn use * | grep Test::File::ShareDir
t/09.HTTP.t:7:use Test::File::ShareDir
t/03.Base.t:7:use Test::File::ShareDir
t/00.Dmarc.t:7:use Test::File::ShareDir
t/06.Result.t:7:use Test::File::ShareDir
t/26.Report.Sender.t:10:use Test::File::ShareDir
t/21.Report.Send.t:7:use Test::File::ShareDir
t/04.PurePerl.t:8:use Test::File::ShareDir
t/17.Report.Aggregate.Schema.t:7:use Test::File::ShareDir -share => { -dist => { 'Mail-DMARC' => 'share' } };
t/11.Report.Store.t:7:use Test::File::ShareDir

It is only there as it is listed manually in d/control.

That would eliminate this whole block:
* libtest-file-sharedir-perl: universe
   - libclass-tiny-perl: universe
   - libfile-copy-recursive-perl: universe
   - libfile-sharedir-perl: universe
     + libclass-inspector-perl: universe
   - libscope-guard-perl: universe

Looking at d/control:

Package: libmail-dmarc-perl
Architecture: all
Depends: ${misc:Depends},
         ${perl:Depends},
         libconfig-tiny-perl,
         libio-socket-ssl-perl,
         libfile-sharedir-perl,
         libnet-dns-perl,
         libnet-idn-encode-perl,
         libnet-ip-perl,
         libnet-ssleay-perl,
         libemail-mime-perl,
         libtest-file-sharedir-perl,
         libemail-sender-perl,
         libdbix-simple-perl,
         libdbd-sqlite3-perl,
         libtest-output-perl,
         libregexp-common-perl,
         libsocket6-perl,
         liburi-perl,
         libxml-libxml-perl,
         publicsuffix,

That is a long list of manual depends which might be wrong.

I think there are two tasks here, now seeming like work but potentially eliminating a lot more work.
0. check code for candidates e.g.
   # Install libs listed
   $ apt install lib...
   $ dpkg -L lib...
   # find its include path like
   # /usr/share/perl5/Config/Tiny.pm
   # Check for usage of that

Example of a potentially real dependency:
# grep -Hrn use * | grep Config::Tiny
lib/Mail/DMARC/Base.pm:8:use Config::Tiny;

1. Remove all the manual dependencies, see what just ${perl:Depends} detects
2. Use libmail-dmarc-perl without them installed, does it still work

Once confirmed, update the dependency tree in the bug and in the package.

As you @Miriam have found yourself furthermore there is this in Install.md

NOTE: Most of the dependencies are optionally required for the DMARC reporting features. Mail::DMARC will perform validation with only these modules:

    Regexp::Common
    Config::Tiny
    File::ShareDir
    Net::DNS::Resolver
    Net::IP
    Socket6

So an approach could be a much more limited libmail-dmarc-perl in main and a separated only suggested package libmail-dmarc-perl-reporting which adds the rest. Doing this does not prevent considering to add the reporting as well in the future and is independent to the check which dependencies might be entirely non-needed.

Of these only the two here might be needed then:
* libfile-sharedir-perl: universe
+ libclass-inspector-perl: universe

AFAICS libtest-file-sharedir-perl is only used in tests:

It is only there as it is listed manually in d/control.

That would eliminate this whole block:
 * libtest-file-sharedir-perl: universe
   - libclass-tiny-perl: universe
   - libfile-copy-recursive-perl: universe
   - libfile-sharedir-perl: universe
     + libclass-inspector-perl: universe
   - libscope-guard-perl: universe

Looking at d/control:

That is a long list of manual depends which might be wrong.

Example of a potentially real dependency:
# grep -Hrn use * | grep Config::Tiny
lib/Mail/DMARC/Base.pm:8:use Config::Tiny;

1. Remove all the manual dependencies, see what just ${perl:Depends} detects
2. Use libmail-dmarc-perl without them installed, does it still work

Once confirmed, update the dependency tree in the bug and in the package.

As you @Miriam have found yourself furthermore there is this in Install.md

NOTE: Most of the dependencies are optionally required for the DMARC reporting features. Mail::DMARC will perform validation with only these modules:

Regexp::Common
    Config::Tiny
    File::ShareDir
    Net::DNS::Resolver
    Net::IP
    Socket6

Of these only the two here might be needed then:
 * libfile-sharedir-perl: universe
   + libclass-inspector-perl: universe

Revision history for this message

Miriam España Acebal (mirespace) wrote on 2023-10-05:

Download full text (4.0 KiB)

TL;DR We could split the dmarc package into validation (in main) and reporting (suggested to validation, in universe). Still working in checking it through spamassassin. Packages to be MIR:

     libfile-sharedir-perl
       + libclass-inspector-perl
     libnet-idn-encode-perl
     libnet-ip-perl
     libregexp-common-perl

I went throught the list of dependencies declared in the control file as exposed in the comment above, plus doing a matching of what perl modules were used in the test build suite provided in the libmail-dmarc-perl package, in the following sense:

- the module MAIL::DMARC::* does a "use" or "require" of perl modules provided by these X perl packages.
- The t/*.test test in libmail-dmarc-perl's source tree that test the above module use or require these X perl packages.

After that, I splitted the libmail-dmarc-perl package into validation functionality and reporting feature according to the above [1], wich coincides with the ones that are mentioned in the INSTALL.md for validation:

     libconfig-tiny-perl,
     libfile-sharedir-perl,
  libnet-dns-perl,
     libnet-idn-encode-perl,
     libnet-ip-perl,
     libregexp-common-perl,
     libsocket6-perl,
  liburi-perl,

I used the above tests as a usability check of the split packages, doing a prove -v t/*.test with the packages installed (not at build time). First, only with the validation package, later installing also the reporting package for the t/*.Report.*t tests.

Furthermore, the doubt about all of this could be ... is enough the validation functionality of dmarc for the spamassassin plugin? Yes, with an exception that it's already optional: saving reports, that due to the comment, seems that the Store module of DMARC wasn't a submodule of DMARC::Report at the beginning of this perl implementation of DMARC.

Spamassasin dmarc plugin [2] only uses the MAIL::DMARC::PurePerl module [3] and, inside it, the validate function in particular [4]. However, is true that it also could use the save_aggregate function if the dmarc_save_reports variable is set throught mail-dmarc.ini to 1 (defaults is 0 [5], and also in the ini file [6]). That function will need the Mail::DMARC::Report::Store module and the Mail::DMARC::Report::URI module.

It would need a third verification for the splitting: to test it from spamassasin. It has also a t/dmarc.t test [7], that is skipped in building time nowadays because tests involving net are disabled (logical in our infra). I'm working on how to run this test properly or how it can be re-used for this needed check.

So, the packages to be MIR processed in the case of splitting (validation package in main, reporting package in universe and suggested to validation package) are:

libfile-sharedir-perl
+ libclass-in...

TL;DR We could split the dmarc package into validation (in main) and reporting (suggested to validation, in universe). Still working in checking it through spamassassin. Packages to be MIR:

libfile-sharedir-perl
       + libclass-inspector-perl
     libnet-idn-encode-perl
     libnet-ip-perl
     libregexp-common-perl

- Creating two d/*.install files for deploying MAIL::DMARC::* modules according with validation/reporting: all the DMARC::Report::* modules go to the reporting package, and associated  script located in the source tree on /bin folder.
- Splitting the binary dependencies between validation functionality and reporting in the d/control file, as ${perl:Depends} is not calculating anything  on its end (maybe due to [8])
  
     libconfig-tiny-perl,
     libfile-sharedir-perl,
	 libnet-dns-perl,
     libnet-idn-encode-perl,
     libnet-ip-perl,
     libregexp-common-perl,
     libsocket6-perl,
	 liburi-perl,

Spamassasin dmarc plugin [2] only uses the MAIL::DMARC::PurePerl module [3] and, inside it, the validate function in particular [4]. However, is true that it also could use the save_aggregate function if the dmarc_save_reports variable is set throught mail-dmarc.ini to 1 (defaults is 0 [5],  and also in the ini file [6]). That function will need the Mail::DMARC::Report::Store module and the Mail::DMARC::Report::URI module.

So, the packages to be MIR processed in the case of splitting (validation package in main, reporting package in universe and suggested to validation package) are:

libfile-sharedir-perl
       + libclass-inspector-perl
     libnet-idn-encode-perl
     libnet-ip-perl
     libregexp-common-perl

[1] (https://launchpad.net/~mirespace/+archive/ubuntu/libmail-dmarc-perl)
[2] (https://git.launchpad.net/ubuntu/+source/spamassassin/tree/lib/Mail/SpamAssassin/Plugin/DMARC.pm)
[3] (https://git.launchpad.net/ubuntu/+source/spamassassin/tree/lib/Mail/SpamAssassin/Plugin/DMARC.pm#n242)
[4] (https://git.launchpad.net/ubuntu/+source/spamassassin/tree/lib/Mail/SpamAssassin/Plugin/DMARC.pm#n322)
[5] (https://git.launchpad.net/ubuntu/+source/spamassassin/tree/lib/Mail/SpamAssassin/Plugin/DMARC.pm#n111)
[6] (https://git.launchpad.net/ubuntu/+source/libmail-dmarc-perl/tree/share/mail-dmarc.ini#n21)
[7] (https://git.launchpad.net/ubuntu/+source/spamassassin/tree/t/dmarc.t)
[8] (https://www.debian.org/doc/packaging-manuals/perl-policy/ch-module_packages.html#id-1.6.5.4.2.4)

Revision history for this message

Miriam España Acebal (mirespace) wrote on 2023-10-05:

libmail-dmarc-perl-split.debdiff Edit (9.2 KiB, text/plain)

The first unpolished approach of splitting the package (used mainly to test the needed-to-be dependencies).
Debdiff between archive version and ppa package

Revision history for this message

Miriam España Acebal (mirespace) wrote on 2023-10-06:

Bad news... for making spamassassin's dmarc.t test working, we need the following files to allow the requires of the dmarc PurePerl module (perl -e "requires MAIL::DMARC::PurePerl;"):

lib/Mail/DMARC/Report/URI.pm
lib/Mail/DMARC/Report.pm
lib/Mail/DMARC/Report/Aggregate.pm
lib/Mail/DMARC/Report/Aggregate/Metadata.pm
lib/Mail/DMARC/Report/Send.pm
lib/Mail/DMARC/Report/Send/SMTP.pm
lib/Mail/DMARC/Report/Send/HTTP.pm
lib/Mail/DMARC/Report/Store.pm
lib/Mail/DMARC/Report/Receive.pm
lib/Mail/DMARC/Report/Aggregate/Record.pm
lib/Mail/DMARC/Report/Aggregate/Record/Identifiers.pm
lib/Mail/DMARC/Report/Aggregate/Record/Auth_Results/
lib/Mail/DMARC/Report/Aggregate/Record/Auth_Results.pm
lib/Mail/DMARC/Report/Aggregate/Record/Row.pm
lib/Mail/DMARC/Report/Aggregate/Record/Row/Policy_Evaluated.pm

plus

apt install libxml-libxml-perl
apt install libemail-mime-perl

which will introduce this needed MIR bug tree, apart from reconsidering this initial splitting by pure Report modules:

* libemail-mime-perl
   - libemail-messageid-perl
   - libemail-mime-contenttype-perl
     + libtext-unidecode-perl
   - libemail-mime-encodings-perl
   - libemail-simple-perl

Still is 11 versus 44 to be MIR processed.

Revision history for this message

Miriam España Acebal (mirespace) wrote on 2023-10-06:

The above is still for the use of the save_aggregate function on MAIL:DMARC that is called on MAIL::DMARC:PurePerl at line 48, inside the validate function called from Mail::SpamAssassin::Plugin::DMARC
at line 322.

Thinking about what from the dmarc tests on spamassasin is totally necessary or not if we could consider the autosave report disabled by default (that's it).

Revision history for this message

Miriam España Acebal (mirespace) wrote on 2023-10-10:

#10

Another possibility is not to split the package but to move all the dependencies related to Reporting features from binary dependencies to Suggested. With this, we could avoid touching dmarc or spamassassin code (importing partially subs with autoload) and supporting only validation feature, in theory.

Focussing on:

- the modules that need to be imported in all the cases (still wip on filling this bugs).
- Check the not-split-but-reporting-dependencies-suggested way.

Next step: checking with upstream this separation on reporting/validation

Miriam España Acebal (mirespace) on 2023-10-16

description:

updated

Miriam España Acebal (mirespace) on 2023-10-16

description:	updated
description:	updated

Miriam España Acebal (mirespace) on 2023-10-17

description:

updated

Miriam España Acebal (mirespace) on 2023-10-17

description:

updated

Miriam España Acebal (mirespace) on 2023-10-17

description:

updated

Revision history for this message

Miriam España Acebal (mirespace) wrote on 2023-10-17:

#11

Dear MIR approval team:

The bugs for the essential 11 perl modules to be promoted are filed. At the time I'm writing this, pending your review are the following:

https://bugs.launchpad.net/ubuntu/+source/libfile-sharedir-perl/+bug/2039566
https://bugs.launchpad.net/ubuntu/+source/libclass-inspector-perl/+bug/2039569
https://bugs.launchpad.net/ubuntu/+source/libregexp-common-perl/+bug/2039563
https://bugs.launchpad.net/ubuntu/+source/libnet-idn-encode-perl/+bug/2038929
https://bugs.launchpad.net/ubuntu/+source/libnet-ip-perl/+bug/2039456

Three more bugs were filed in advance to the above (for libemail-sender-perl, libemail-abstract-perl and libthrowable-perl). Please don't prioritize these three over the others above.

Checking in the meantime the dependency separation on validation/reporting without splitting the code in two packages.

Thanks in advance and for your patient!

Revision history for this message

Miriam España Acebal (mirespace) wrote on 2023-11-03:

#12

The t/dmarc.t on spamassassin passes using the libmail-dmarc-perl package that puts all the non-necessary modules for validation as suggested packages (it's on ppa:mirespace/libmail-dmarc-perl-suggested).

Following spamassassin/t/README, and commenting the line 17 on t/dmarc.t for net tests disabled (while looking for a more proper way):

root@Mspamassasin-suggested:~/spamassassin# make test TEST_FILES="t/dmarc.t"
"/usr/bin/perl" build/mkrules --exit_on_no_src --src rulesrc --out rules --manifest MANIFEST --manifestskip MANIFEST.SKIP
mkrules: no rules updated
"/usr/bin/perl" build/preprocessor -Mvars -DVERSION="4.000000" -DPREFIX="/usr/local" -DDEF_RULES_DIR="/usr/local/share/spamassassin" -DLOCAL_RULES_DIR="/etc/mail/spamassassin" -DLOCAL_STATE_DIR="/var/lib/spamassassin" -DINSTALLSITELIB="/usr/local/share/perl/5.36.0" -DCONTACT_ADDRESS="the administrator of that system" -DRE2C_BIN="re2c" -Msharpbang -Mconditional -DPERL_BIN=""/usr/bin/perl"" -DPERL_WARN="" -DPERL_TAINT="" -m755 -isa-update.raw -osa-update
cp sa-update blib/script/sa-update
"/usr/bin/perl" -MExtUtils::MY -e 'MY->fixin(shift)' -- blib/script/sa-update
PERL_DL_NONLAZY=1 "/usr/bin/perl" "-MExtUtils::Command::MM" "-MTest::Harness" "-e" "undef *Test::Harness::Switches; test_harness(0, 'blib/lib', 'blib/arch')" t/dmarc.t
t/dmarc.t .. Nov 3 12:36:16.977 [8195] warn: deprecated method; size() is an alias of "UDPsize()" at ../blib/lib/Mail/SpamAssassin/DnsResolver.pm line 602.
t/dmarc.t .. 1/18 Nov 3 12:36:18.906 [8197] warn: deprecated method; size() is an alias of "UDPsize()" at ../blib/lib/Mail/SpamAssassin/DnsResolver.pm line 602.
t/dmarc.t .. 3/18 Nov 3 12:36:21.247 [8199] warn: deprecated method; size() is an alias of "UDPsize()" at ../blib/lib/Mail/SpamAssassin/DnsResolver.pm line 602.
t/dmarc.t .. 5/18 Nov 3 12:36:23.737 [8201] warn: deprecated method; size() is an alias of "UDPsize()" at ../blib/lib/Mail/SpamAssassin/DnsResolver.pm line 602.
t/dmarc.t .. 7/18 Nov 3 12:36:26.153 [8203] warn: deprecated method; size() is an alias of "UDPsize()" at ../blib/lib/Mail/SpamAssassin/DnsResolver.pm line 602.
t/dmarc.t .. 9/18 Nov 3 12:36:29.117 [8205] warn: deprecated method; size() is an alias of "UDPsize()" at ../blib/lib/Mail/SpamAssassin/DnsResolver.pm line 602.
t/dmarc.t .. 11/18 Nov 3 12:36:32.796 [8207] warn: deprecated method; size() is an alias of "UDPsize()" at ../blib/lib/Mail/SpamAssassin/DnsResolver.pm line 602.
t/dmarc.t .. 13/18 Nov 3 12:36:35.338 [8209] warn: deprecated method; size() is an alias of "UDPsize()" at ../blib/lib/Mail/SpamAssassin/DnsResolver.pm line 602.
t/dmarc.t .. 15/18 Nov 3 12:36:37.374 [8211] warn: deprecated method; size() is an alias of "UDPsize()" at ../blib/lib/Mail/SpamAssassin/DnsResolver.pm line 602.
t/dmarc.t .. ok
All tests successful.
Files=1, Tests=18, 31 wallclock secs ( 0.02 usr 0.00 sys + 12.18 cusr 0.88 csys = 13.08 CPU)
Result: PASS

So I believe we can continue only with the 11 perl modules that are implied on Validation, and moving the rest to suggested.

Following spamassassin/t/README, and commenting the line 17 on t/dmarc.t for net tests disabled (while looking for a more proper way):

root@Mspamassasin-suggested:~/spamassassin# make test TEST_FILES="t/dmarc.t"
"/usr/bin/perl" build/mkrules --exit_on_no_src --src rulesrc --out rules --manifest MANIFEST --manifestskip MANIFEST.SKIP
mkrules: no rules updated
"/usr/bin/perl" build/preprocessor  -Mvars -DVERSION="4.000000" -DPREFIX="/usr/local" -DDEF_RULES_DIR="/usr/local/share/spamassassin" -DLOCAL_RULES_DIR="/etc/mail/spamassassin" -DLOCAL_STATE_DIR="/var/lib/spamassassin" -DINSTALLSITELIB="/usr/local/share/perl/5.36.0" -DCONTACT_ADDRESS="the administrator of that system" -DRE2C_BIN="re2c" -Msharpbang -Mconditional -DPERL_BIN=""/usr/bin/perl"" -DPERL_WARN="" -DPERL_TAINT="" -m755 -isa-update.raw -osa-update
cp sa-update blib/script/sa-update
"/usr/bin/perl" -MExtUtils::MY -e 'MY->fixin(shift)' -- blib/script/sa-update
PERL_DL_NONLAZY=1 "/usr/bin/perl" "-MExtUtils::Command::MM" "-MTest::Harness" "-e" "undef *Test::Harness::Switches; test_harness(0, 'blib/lib', 'blib/arch')" t/dmarc.t
t/dmarc.t .. Nov  3 12:36:16.977 [8195] warn: deprecated method; size() is an alias of "UDPsize()" at ../blib/lib/Mail/SpamAssassin/DnsResolver.pm line 602.
t/dmarc.t .. 1/18 Nov  3 12:36:18.906 [8197] warn: deprecated method; size() is an alias of "UDPsize()" at ../blib/lib/Mail/SpamAssassin/DnsResolver.pm line 602.
t/dmarc.t .. 3/18 Nov  3 12:36:21.247 [8199] warn: deprecated method; size() is an alias of "UDPsize()" at ../blib/lib/Mail/SpamAssassin/DnsResolver.pm line 602.
t/dmarc.t .. 5/18 Nov  3 12:36:23.737 [8201] warn: deprecated method; size() is an alias of "UDPsize()" at ../blib/lib/Mail/SpamAssassin/DnsResolver.pm line 602.
t/dmarc.t .. 7/18 Nov  3 12:36:26.153 [8203] warn: deprecated method; size() is an alias of "UDPsize()" at ../blib/lib/Mail/SpamAssassin/DnsResolver.pm line 602.
t/dmarc.t .. 9/18 Nov  3 12:36:29.117 [8205] warn: deprecated method; size() is an alias of "UDPsize()" at ../blib/lib/Mail/SpamAssassin/DnsResolver.pm line 602.
t/dmarc.t .. 11/18 Nov  3 12:36:32.796 [8207] warn: deprecated method; size() is an alias of "UDPsize()" at ../blib/lib/Mail/SpamAssassin/DnsResolver.pm line 602.
t/dmarc.t .. 13/18 Nov  3 12:36:35.338 [8209] warn: deprecated method; size() is an alias of "UDPsize()" at ../blib/lib/Mail/SpamAssassin/DnsResolver.pm line 602.
t/dmarc.t .. 15/18 Nov  3 12:36:37.374 [8211] warn: deprecated method; size() is an alias of "UDPsize()" at ../blib/lib/Mail/SpamAssassin/DnsResolver.pm line 602.
t/dmarc.t .. ok     
All tests successful.
Files=1, Tests=18, 31 wallclock secs ( 0.02 usr  0.00 sys + 12.18 cusr  0.88 csys = 13.08 CPU)
Result: PASS

So I believe we can continue only with the 11 perl modules that are implied on Validation, and moving the rest to suggested.

Revision history for this message

Miriam España Acebal (mirespace) wrote on 2023-11-13 (last edit on 2023-11-13):

#13

I'm sure we can go with this dependency splitting into validation (for binary/runtime dependencies ) and reporting (suggested dependencies): after a talk with Bryce (thanks!), passing a mail (downloaded from your inbox) through spamassassin directly and checking if the DMARC line is present in the spamassassin report:

root@Mspamassasin-suggested:~# spamc -R < message-mattermost-hey.eml | grep DMARC
-0.0 DMARC_PASS DMARC pass policy

with

root@Mspamassasin-suggested:~# apt-cache policy libmail-dmarc-perl
libmail-dmarc-perl:
  Installed: 1.20230215-1~mirespace1
  Candidate: 1.20230215-1
  Version table:
     1.20230215-1 500
        500 http://archive.ubuntu.com/ubuntu mantic/universe amd64 Packages
*** 1.20230215-1~mirespace1 500
        500 https://ppa.launchpadcontent.net/mirespace/libmail-dmarc-perl-suggested/ubuntu mantic/main amd64 Packages
        100 /var/lib/dpkg/status

after

root@Mspamassasin-suggested:~# sudo apt install libmail-dmarc-perl=1.20230215-1~mirespace1
[...]
Suggested packages:
libdbd-sqlite3-perl libdbix-simple-perl libemail-sender-perl libnet-imap-simple-perl libnet-server-perl libnet-smtps-perl libtest-file-sharedir-perl
libtest-output-perl libmojolicious-perl libscalar-number-perl libxml-sax-expatxs-perl
[..]
0 upgraded, 26 newly installed, 0 to remove and 0 not upgraded.
[..]
root@Mspamassasin-suggested:~#

In a fresh installation of libmail-dmarc-perl in Mantic (without spamassassin previously installed), we will have:

0 upgraded, 149 newly installed, 0 to remove and 0 not upgraded.

and if we install the splitted-dependencies package, we will have:

0 upgraded, 66 newly installed, 0 to remove and 0 not upgraded.

I'll make the modifications for the Noble package (that would be -ubuntu1 suffixed then) and
I will update the description in this bug also for:
- mentioning there the packages used in the DMARC validation process only that will need MIR
- testing the package [updating some of the Quality assurance sections]

root@Mspamassasin-suggested:~# spamc -R  < message-mattermost-hey.eml | grep DMARC
-0.0 DMARC_PASS             DMARC pass policy

with

root@Mspamassasin-suggested:~# apt-cache policy libmail-dmarc-perl
libmail-dmarc-perl:
  Installed: 1.20230215-1~mirespace1
  Candidate: 1.20230215-1
  Version table:
     1.20230215-1 500
        500 http://archive.ubuntu.com/ubuntu mantic/universe amd64 Packages
 *** 1.20230215-1~mirespace1 500
        500 https://ppa.launchpadcontent.net/mirespace/libmail-dmarc-perl-suggested/ubuntu mantic/main amd64 Packages
        100 /var/lib/dpkg/status

after

root@Mspamassasin-suggested:~# sudo apt install libmail-dmarc-perl=1.20230215-1~mirespace1
[...]
Suggested packages:
  libdbd-sqlite3-perl libdbix-simple-perl libemail-sender-perl libnet-imap-simple-perl libnet-server-perl libnet-smtps-perl libtest-file-sharedir-perl
  libtest-output-perl libmojolicious-perl libscalar-number-perl libxml-sax-expatxs-perl
[..]
0 upgraded, 26 newly installed, 0 to remove and 0 not upgraded.
[..]
root@Mspamassasin-suggested:~#

In a fresh installation of libmail-dmarc-perl in Mantic (without spamassassin previously installed), we will have:

0 upgraded, 149 newly installed, 0 to remove and 0 not upgraded.

and if we install the splitted-dependencies package, we will have:

0 upgraded, 66 newly installed, 0 to remove and 0 not upgraded.

I'll make the modifications for the Noble package (that would be -ubuntu1 suffixed then) and
I will update the description in this bug also for:
 -  mentioning there the packages used in the DMARC validation process only that will need MIR  
 -  testing the package [updating some of the Quality assurance sections]

Miriam España Acebal (mirespace) on 2023-11-13

description:

updated

Revision history for this message

Bryce Harrington (bryce) wrote on 2023-11-14:

#14

Glad to see you are able to verify the DMARC entry after running spamc. Why don't you also find an email that does *not* pass DMARC to verify a negative result. If you have some spam emails on hand I'll bet at least one of them fails. Or you could create one synthetically by putting typos into the From header to a non-existent domain.