exim4-daemon-heavy: please compile with DMARC support

[Timothy Allen]

It seems that SUPPORT_SPF=yes is now in the default compile flags for exim4-daemon-heavy in Debian, as of bookworm.

However, SUPPORT_DMARC=yes, which has been available since 4.93 (released in January 2020), has not yet been added.

Please could you add SUPPORT_DMARC=yes to the compile flags for exim4-daemon-heavy.

In addition, ARC still has experimental status in Exim, but major mail providers are starting to require ARC support in connecting clients. Would it be possible to add EXPERIMENTAL_ARC=yes to exim4-daemon-heavy in time for the next LTS as well?

[Lena Voytek (lvoytek)]

Thanks for the bug report! I agree DMARC and even ARC support would be good to have here. Unfortunately, as with libspf2, libopendmarc is a universe package and would be difficult to justify having as a build dependency. It's possible this could be changed though. An alternative to this may be to use opendmarc alongside exim4 to support it like Ubuntu does with spf-tools-perl. Either way I'll see what we can do to support this.

[Robie Basak (racb)]

I think it's probably worth looking into understanding what it would take to support DMARC in our build. To be clear, I'm not necessarily committing to doing so - it depends on what it would take.

[Bryce Harrington (bryce)]

It looks like the feature has one dependency, on opendmarc, which is in universe so would need a MIR. Further, that package depends on dbconfig-mysql | dbconfig-no-thanks, both also universe packages but perhaps these may be simple to deal with. There are also several perl modules marked as Recommends, that would either need MIR'd or reduced to Suggests.

I'm not spotting what Debian has planned for enabling this in exim4, but I would guess they should have a similar interest to us in having it enabled out of the box. They don't have the universe-vs-main situation that we do, so I wonder if other issues such as stability concerns may be an issue?

[Bryce Harrington (bryce)]

Please file a separate bug for enabling EXPERIMENTAL_ARC, since that seems to be a discrete feature from DMARC. Offhand, the situation needing it sounds like it's limited to intermediaries - i.e. mail forwarders and mailing lists - so may be a narrower use case and thus might be better to wait until it is promoted from experimental. But go ahead and make your case in the new bug report if it seems more important than that, and we'll consider.

(It's unclear from a quick look if ARC support has new dependencies, so can't say if it also would require a MIR. If there are no new dependencies for it, that may make the consideration simpler.)

[Timothy Allen (tim-treehouse)]

Thank you, I have split the EXPERIMENTAL_ARC request into a new bug report, at https://bugs.launchpad.net/ubuntu/+source/exim4/+bug/2048068 .

In terms of the universe-vs-main issue, I'm not fully conversant with the overall policy requirements. However, personally, I'd be content if exim4-daemon-heavy were moved into universe, while the rest of the exim4 packages remain in main (if such a thing is possible), or if a new super-super-set package (exim4-daemon-all?) were created in universe, containing libopendmarc2/libspf2-2 dependencies.

Thank you all for the speedy analysis!

[Mitchell Dzurick (mitchdz)]

I'm still planning to do this, but haven't finished the paperwork just yet, mainly want to investigate the security side of things. Apologies on the delays.