Dear Maintainer, Noah,

I'm working on making the libmail-dmarc-perl package a package that
belongs to the Ubuntu main repository (5-10 years of support by the Ubuntu team), through a MIR (Main Inclusion request) process [1].

The main reason behind that is that this package is used by spamassassin
(already in main). Curious thing is that, by now, spamassassin is the
only package that uses libmail-dmarc-perl as dependency, which supposes an advantage
in our case.

spamassassin only uses the validation feature of Mail::DMARC and, as we
can read in the INSTALL.md file of src:libmail-dmarc-perl, line 21:

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

I checked also in the spamassassin's code that the validation feature is only used: 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.

Therefore, I separated dependencies in the binary package depending on their use. Modules used in validation remain as binary dependencies and the rest, used in reporting, are moved to suggested dependencies, still availables. I attached it here as a patch.

Both test suites, spamassassin and libmail-dmarc-perl t/*.t folders,
passes. Also, I made a DEP-8 test (that I can fordward to you if this
split seems reasonable/interesting) to you.


As a collateral effect, the split reduces the number of packages that need to be installed when used by spamassassin, saving space.

I don't know if you find this approach interesting, but anyway.... I thought it was worth sharing it with you. What do you think?

Thanks in advance,

Miriam España Acebal
Software Engineer II - Ubuntu PublicCloud/Server
Canonical Ltd.

[1] https://bugs.launchpad.net/ubuntu/+source/libmail-dmarc-perl/+bug/2023971
[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

On Tue, Dec 12, 2023 at 06:14:02PM +0100, Miriam España Acebal wrote:

<snip>

<snip>

First, let me apologize for the long response latency.

I think this is likely a very sensible approach; libmail-dmarc-perl was
only packaged for Debian in order to support SpamAssassin, and (as far
as I know) SA is still the only package using it.  Therefore, it makes
sense to optimize the packaging somewhat to support SA's use case.

I have not yet looked into your patch or verified that it works with the
newer versions of the package, but I will review the complete situation
(patch, rdeps, etc) in depth in the near future and apply your patch if
it still makese sense to do so.

Thanks
noah

Hi Noah,

I’m currently checking which lib*-perl packages are not yet maintained
within the Debian Perl Group. While libmail-dmarc-perl seems to be in
good shape under your maintenance, I thought it might also benefit from
being maintained in the Perl Group. The team has nice infrastructure for
regular automated improvements, which can help reduce the burden on
individual maintainers.

I’m not very active in the team myself, but I really appreciate having
some of my Perl packages in their Salsa space for exactly this reason.

If you find the idea appealing, I’d be happy to help with moving
libmail-dmarc-perl to the group, applying the patch for the bug in CC,
and updating to the latest upstream release. Of course, I’d ask for your
review before uploading (or leave the final upload to you, if you
prefer).

Kind regards
    Andreas.

Yes, please move it.  IIRC there was a really really slow moving thread
about this at one point.

There's a new upstream release that should be packaged, but it's
probably best to get the maintainer metadata refreshed first, and then
follow up with the new version.

Thanks
noah

Hi Noah,

thank you for the quick response.

Am Thu, Sep 04, 2025 at 03:45:46PM -0400 schrieb Noah Meyerhans:

OK, I prepared something here:

https://salsa.debian.org/perl-team/modules/packages/libmail-dmarc-perl

I admit I do not see any good reason to do two separate uploads.  So
I've prepared the new upstream for your comfort.  You might like to
review the repository and feel free to upload at your convenience.
Salsa CI is passing[1] all tests.

Hope this helps
    Andreas.

[1] https://salsa.debian.org/perl-team/modules/packages/libmail-dmarc-perl/-/pipelines/927962