SA Bugzilla – Bug 7261
Replace Mail::SPF or take ownership of module
Last modified: 2022-03-06 12:45:47 UTC
Mail::SPF appears to be abandonware, and the bugs for it are adding up. It depends on the Error module, which explicitly says it should not be used, it depends on deprecated functions from Net::DNS, and there are a ton of open issues for it on CPAN. The author appears to be AWOL. Such a critical portion of SA functionality should not be relegated to abandonware.
workaround is to use pypolicyd-spf in mta stage and then in sa reuse headers from it
Also see Bug 7224
> Mail::SPF appears to be abandonware, and the bugs for it are adding up. It > depends on the Error module, which explicitly says it should not be used, it > depends on deprecated functions from Net::DNS, and there are a ton of open > issues for it on CPAN. The author appears to be AWOL. Such a critical > portion of SA functionality should not be relegated to abandonware. It would be nice if somebody took active maintainership of this module. Quanah is present on this scene (Amavis + SpamAssassin) for a long time, so I'd be happy with the proposed. As this is an Apache project, changes would still need to be documented in the Bugzilla, subject to lazy consensus, and CLA needs to be observed. In my opinion the more extensive changes should only be applied to the trunk. The 3.4 branch has a couple of important fixes now, so I think it should be released as 3,4.2 sooner rather than later, with no further extensive changes, just essential minimalistic bug fixes. As for Mail::SPF in trunk, the old Mail::SPF::Query (last updated 2006-02) usage can now be ripped out - in favor of Mail::SPF, which itself hasn't seen an update for the last two years (2013-07).
I like the idea of a 3.4.2 soon. Though, I'm very hesitant to take on maintenance of a module for the project, though it might be necessary. Regards, KAM
This looks like a good canditate as it allows to do own async lookups: https://metacpan.org/pod/Mail::SPF::Iterator But as there is already the ability to parse Received-SPF header from MTA, doesn't seem like there's much payoff for the work required to implement a new module. I would just encourage people to use MTA processing. Removed any Mail::SPF::Query related stuff from trunk: Sending INSTALL Sending UPGRADE Sending lib/Mail/SpamAssassin/Plugin/SPF.pm Sending t/spf.t Transmitting file data ....done Committing transaction... Committed revision 1844324.
So this removes any SPF processing from 4.0.0. So rules like SPF_NONE, etc. won't work anymore?
Atm trunk relies on received headers inserted by the mta or it uses Mail::SPF (even if it is no more maintained, Mail::Spf::Query support has been removed). I think we should switch from Mail::SPF to Mail::SPF::Iterator which is maintained.
None of the Mail::SPF issues look very critical and it's packages are available in all distros unlike Mail::SPF::Iterator stuff.. Using Mail::SPF::Iterator and Mail::DKIM::Iterator would be a nice improvement, but unless someone is willing to code this, it's just a wishlist. Personally I have no incentive, since existing stuff works fine enough and opendkim/opendmarc cache any queries from MTA level.
Postponing into future, I doubt anyone can tackle this soon