Bug 7261 - Replace Mail::SPF or take ownership of module
Summary: Replace Mail::SPF or take ownership of module
Status: NEW
Alias: None
Product: Spamassassin
Classification: Unclassified
Component: Building & Packaging (show other bugs)
Version: 3.4.1
Hardware: PC Windows 7
: P2 enhancement
Target Milestone: Future
Assignee: SpamAssassin Developer Mailing List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-11-09 06:59 UTC by Quanah Gibson-Mount
Modified: 2022-03-06 12:45 UTC (History)
4 users (show)



Attachment Type Modified Status Actions Submitter/CLA Status

Note You need to log in before you can comment on or make changes to this bug.
Description Quanah Gibson-Mount 2015-11-09 06:59:01 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.
Comment 1 Benny Pedersen 2015-11-09 15:05:58 UTC
workaround is to use pypolicyd-spf in mta stage and then in sa reuse headers from it
Comment 2 Kevin A. McGrail 2015-11-09 21:33:38 UTC
Also see Bug 7224
Comment 3 Mark Martinec 2015-11-10 13:06:55 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.

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).
Comment 4 Kevin A. McGrail 2015-11-10 15:40:10 UTC
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
Comment 5 Henrik Krohns 2018-10-19 10:21:50 UTC
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.
Comment 6 Kevin A. McGrail 2019-06-18 00:12:42 UTC
So this removes any SPF processing from 4.0.0.  So rules like SPF_NONE, etc. won't work anymore?
Comment 7 Giovanni Bechis 2019-06-18 08:27:31 UTC
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.
Comment 8 Henrik Krohns 2019-06-18 09:18:20 UTC
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.
Comment 9 Henrik Krohns 2022-03-06 12:45:47 UTC
Postponing into future, I doubt anyone can tackle this soon