Comment 6 for bug 2023971

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:

- 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,

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-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)