[MIR] libmail-dmarc-perl
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
libmail-dmarc-perl (Ubuntu) |
Fix Released
|
High
|
Unassigned |
Bug Description
[MIR] libmail-dmarc-perl
Package: libmail-dmarc-perl
-----
Dependency status update (Feb 01, 2024):
On Feb 1, the six needed packages to be promoted to main and their bug status are:
* libmail-dmarc-perl (this bug): bug 2023971, New, Ioanna assigned: pending review, package to be tested at [1] with all the changes required in the other MIR bugs, and the dependency splitting.
* libemail-
-> maintenance by Server Team if we lack upstream support
-> ask for demotion (in the future) if another package if a more
* libfile-
* libclass-
* libnet-ip-perl: bug 2039456 , In progress, unassigned -> ACK by Ioanna, All todos done
* libregexp-
-----
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 [Dependencies] section for detailed dependencies tree) .
However, libmail-dmarc-perl is only used by the spamassassin package, and spamassassin only uses the validation feature of DMARC, so we can narrow the necessary binaries dependencies to be promoted too. Those packages are the following ones (11), which I propose for promotion instead of the complete dependencies tree:
* libemail-mime-perl: universe
MIR bug: https:/
- libemail-
MIR bug: https:/
- libemail-
MIR bug: https:/
+ libtext-
MIR bug: https:/
- libemail-
MIR bug: https:/
- libemail-
MIR bug: https:/
* libfile-
MIR bug https:/
+ libclass-
MIR bug https:/
* libnet-
MIR bug https:/
* libnet-ip-perl: universe
https:/
* libregexp-
MIR bug https:/
The rest would be moved to Suggested dependencies.
[Availability]
The package libmail-dmarc-perl is already in Ubuntu universe.
The package libmail-dmarc-perl builds for the architectures it is designed to work on.
It currently builds and works for architectures: amd64 (all)
Link to package https:/
[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") [0] 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: Spamassassin dmarc plugin [1] only uses the MAIL::DMARC:
libmail-dmarc-perl is a relatively new source package that was proposed for lunar [4] 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.
[0] (https:/
[1] (https:/
[2] (https:/
[3] (https:/
[4] (https:/
[Security]
No CVEs/security issues in this software in the past:
- (0) https:/
- (0) https:/
- (0) https:/
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:/
No `suid` or `sgid` binaries.
No executables in `/sbin` and `/usr/sbin`.
Package does not install services, timers or recurring jobs, but contains an example of a cron job for updating the public_suffix_list (https:/
Package does not open privileged ports (ports < 1024).
Package does not expose any external endpoints.
Package contains extensions to security-sensitive software (filters, scanners, plugins, UI skins, ...): It is the basis for the DMARC plugin of spamassassin, implementing the DMARC policy validation (and reporting).
Upstream's source code includes the build of a web server (dmarc_httpd) and an HTTP client (dmarc_
[Quality assurance - function/usage]
The package works well right after installed with its required installation dependencies.
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/
Processing of emails by spamassassin using its DMARC plugin that uses libmail-dmarc-perl validation function was tested also grabbing an email (i.e, from gmail) and doing:
$ spamc -R < message-
-0.0 DMARC_PASS DMARC pass policy
also, non pass results with an already classified as spam mail (by gmail, cleaning the header):
0.9 DMARC_NONE DMARC none policy
or introducing typos to malform domains/header:
0.0 DMARC_MISSING Missing DMARC policy
For rejection examples, we use the data from spamassassin's test, and we can see:
root@Mspamassas
nodmarc.eml noneko.eml quarko.eml rejectko.eml strictrejectko.eml
root@Mspamassas
1.8 DMARC_REJECT DMARC reject policy
root@Mspamassas
1.8 DMARC_REJECT DMARC reject policy
root@Mspamassas
1.2 DMARC_QUAR DMARC quarantine policy
root@Mspamassas
0.0 DMARC_MISSING Missing DMARC policy
root@Mspamassas
0.9 DMARC_NONE DMARC none policy
I'm working on an autopkgtest that covers this: The code is uploaded but not working yet. For manual testing, you can get the eml messages from this commit:
where d/t/data/nice contains messages that qualifies as PASS due to the DMARC rules (DMARC_PASS) and d/t/data/spam contains messages that are market as REJECT, QUARENTINE, MISSING or NONE.
The specific test on spamassassin for DMARC (t/dmarc.t) was also run successfully (without the implicit net tests on this file):
$ make test TEST_FILES=
"/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=
cp sa-update blib/script/
"/usr/bin/perl" -MExtUtils::MY -e 'MY->fixin(shift)' -- blib/script/
PERL_DL_NONLAZY=1 "/usr/bin/perl" "-MExtUtils:
t/dmarc.t .. Nov 3 12:36:16.977 [8195] warn: deprecated method; size() is an alias of "UDPsize()" at ../blib/
t/dmarc.t .. 1/18 Nov 3 12:36:18.906 [8197] warn: deprecated method; size() is an alias of "UDPsize()" at ../blib/
t/dmarc.t .. 3/18 Nov 3 12:36:21.247 [8199] warn: deprecated method; size() is an alias of "UDPsize()" at ../blib/
t/dmarc.t .. 5/18 Nov 3 12:36:23.737 [8201] warn: deprecated method; size() is an alias of "UDPsize()" at ../blib/
t/dmarc.t .. 7/18 Nov 3 12:36:26.153 [8203] warn: deprecated method; size() is an alias of "UDPsize()" at ../blib/
t/dmarc.t .. 9/18 Nov 3 12:36:29.117 [8205] warn: deprecated method; size() is an alias of "UDPsize()" at ../blib/
t/dmarc.t .. 11/18 Nov 3 12:36:32.796 [8207] warn: deprecated method; size() is an alias of "UDPsize()" at ../blib/
t/dmarc.t .. 13/18 Nov 3 12:36:35.338 [8209] warn: deprecated method; size() is an alias of "UDPsize()" at ../blib/
t/dmarc.t .. 15/18 Nov 3 12:36:37.374 [8211] warn: deprecated method; size() is an alias of "UDPsize()" at ../blib/
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
[Quality assurance - maintenance]
The package is maintained well in Debian/Ubuntu and does
not have too many, long-term & critical, open bugs:
- Ubuntu (0) https:/
- Debian (0) https:/
- Upstream's bug tracker (4) https:/
+ Upstream's repo last activity: https:/
- last commit: in master, Oct 25, 2023
- Issues without answer: 2
- Updated issue/PR: Oct 25, 2023
- last fixed/closed/merged issue: Oct 25, 2023
- last merged PR: Oct 25, 2023
The package has one important/old open bugs on upstream: Invalid XML in generated reports, https:/
The package does not deal with exotic hardware we cannot support
[Quality assurance - testing]
The package runs a test suite on build time, if it fails
it makes the build fail: https:/
Creating new 'Build' script for 'Mail-DMARC' version '1.20230215'
dh_auto_build
/usr/bin/perl Build
Building Mail-DMARC
dh_auto_test
/usr/bin/perl Build test --verbose 1
The package doesn't run an autopkgtest.
[Quality assurance - packaging]
debian/watch is present and works.
debian/control defines a correct Maintainer field : Noah Meyerhans <email address hidden> ( https:/
This package does not yield massive lintian Warnings, Errors
- recent build log of the package https:/
- full output from `lintian --pedantic` :
#source
❯ lintian -EvIL +pedantic --show-overrides
E: libmail-dmarc-perl changes: bad-distributio
W: libmail-dmarc-perl: changelog-
W: libmail-dmarc-perl changes: distribution-
I: libmail-dmarc-perl: typo-in-manual-page messsage message [usr/share/
I: libmail-dmarc-perl: typo-in-manual-page messsage message [usr/share/
P: libmail-dmarc-perl: repeated-
X: libmail-dmarc-perl: application-
X: libmail-dmarc-perl: application-
X: libmail-dmarc-perl: application-
X: libmail-dmarc-perl: application-
X: libmail-dmarc-perl: application-
X: libmail-dmarc-perl: library-
X: libmail-dmarc-perl: library-
X: libmail-dmarc-perl: library-
X: libmail-dmarc-perl: library-
X: libmail-dmarc-perl: library-
#binary
❯ lintian -EvIL +pedantic --show-overrides ../libmail-
I: libmail-dmarc-perl source: out-of-
X: libmail-dmarc-perl source: debian-
X: libmail-dmarc-perl source: libmodule-
X: libmail-dmarc-perl source: update-
This package does not rely on obsolete or about to be demoted packages.
This package has no python2 or GTK2 dependencies.
The package will not be installed by default.
Packaging and build is easy, link to debian/rules: https:/
[UI standards]
Application is not end-user facing (does not need translation).
[Dependencies]
As exposed at the beginning, this package needed initially +-44 MIR bugs (depending on the processing of the Recommends ones).
This is the original dependency tree, only listing on first occurrence:
* libdbd-
MIR bug: https:/
* libdbix-
MIR bug: https:/
* libemail-mime-perl: universe
MIR bug: https:/
- libemail-
MIR bug: https:/
- libemail-
MIR bug: https:/
+ libtext-
MIR bug: https:/
- libemail-
MIR bug: https:/
- libemail-
MIR bug: https:/
* libemail-
MIR bug: https:/
- libemail-
MIR bug: https:/
+ libmodule-
+ libmro-compat-perl: universe
• libclass-c3-perl: universe
◦ libalgorithm-
• libclass-
- libmoox-
- libscalar-
- libthrowable-perl: universe
MIR bug https:/
+ libmoose-perl: universe (Recommends)
• libclass-load-perl: universe
• libclass-
• libdevel-
• libdevel-
• libeval-
◦ libdevel-
· libdevel-
·· libpadwalker-perl: universe
• libmodule-
◦ libdist-
• libpackage-
◦ libscalar-
• libdevel-
◦ libclass-tiny-perl: universe
* libfile-
MIR bug https:/
+ libclass-
MIR bug https:/
* libnet-
MIR bug https:/
* libnet-
- libparse-
* libnet-ip-perl: universe
https:/
* libnet-smtps-perl: universe
* libregexp-
MIR bug https:/
* libtest-
- libfile-
- libfile-
+ libclass-
- libscope-
* libtest-
But, attending on how spamassassin works -explained above-, I believe we can split these dependencies in dependencies used by the reporting feature and dependencies used by validation feature. Walking this way,
the dependencies used in validation remains as needed runtime binary dependencies, and the dependencies used in reporting goes to suggested runtime dependencies. Therefore, only 11 packages would need to go
through the MIR process to satisfy libmail-dmarc-perl dependencies:
* libemail-mime-perl: universe
MIR bug: https:/
- libemail-
MIR bug: https:/
- libemail-
MIR bug: https:/
+ libtext-
MIR bug: https:/
- libemail-
MIR bug: https:/
- libemail-
MIR bug: https:/
* libfile-
MIR bug https:/
+ libclass-
MIR bug https:/
* libnet-
MIR bug https:/
* libnet-ip-perl: universe
https:/
* libregexp-
MIR bug https:/
a package following this scheme was built and it is available for testing on mantic here:
ppa:mirespace/
https:/
and the debdiff (for noble now) is here: https:/
Note that, in this package, there is a suppression of a perl library (on main) that I suspect is not needed, as the package builds well and tests passed also. I opened this question to upstream (https:/
Also, there is this MP (https:/
- refactor for not using libemail-mime-perl (done)
- adding autopkgtest for validating the splitting (wip)
This package passes all the tests explained in the [Quality assurance - function/usage] section.
[Standards compliance]
This package correctly follows FHS and Debian Policy
[Maintenance/Owner]
Owning Team will be the Ubuntu Server Team, if they're not covered already by other teams (the Foundations team has covered maintenance at points in the past).
Team is not yet, but will subscribe to the package before promotion.
This does not use static builds.
This does not use vendored code.
This package is not rust based.
The package successfully built during the most recent test rebuild : https:/
[Background information]
The Package description explains the package well.
Upstream Name is Mail-DMARC .
Link to upstream project https:/
About SSLeay (https:/
but libhttp-tiny-perl is not in use by the debian package because that is provided by perl package itself, so I'm wondering about it yet.
This has been in the archive since this year (Lunar, 1.20211209-1).
Related branches
- Lucas Kanashiro (community): Approve
- Canonical Server Reporter: Pending requested
-
Diff: 54 lines (+10/-0)1 file modifiedsubscriptions.yaml (+10/-0)
description: | updated |
Changed in libmail-dmarc-perl (Ubuntu): | |
status: | Incomplete → New |
Changed in libmail-dmarc-perl (Ubuntu): | |
assignee: | nobody → Miriam España Acebal (mirespace) |
description: | updated |
description: | updated |
description: | updated |
description: | updated |
description: | updated |
description: | updated |
description: | updated |
description: | updated |
description: | updated |
description: | updated |
description: | updated |
description: | updated |
description: | updated |
description: | updated |
description: | updated |
description: | updated |
description: | updated |
description: | updated |
description: | updated |
description: | updated |
description: | updated |
description: | updated |
description: | updated |
description: | updated |
Changed in libmail-dmarc-perl (Ubuntu): | |
status: | Incomplete → New |
description: | updated |
Changed in libmail-dmarc-perl (Ubuntu): | |
assignee: | Miriam España Acebal (mirespace) → nobody |
Changed in libmail-dmarc-perl (Ubuntu): | |
assignee: | nobody → Ioanna Alifieraki (joalif) |
description: | updated |
Changed in libmail-dmarc-perl (Ubuntu): | |
assignee: | nobody → Miriam España Acebal (mirespace) |
tags: | added: sec-3890 |
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.