You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@spamassassin.apache.org by bu...@bugzilla.spamassassin.org on 2015/11/09 07:59:01 UTC

[Bug 7261] New: Replace Mail::SPF or take ownership of module

https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7261

            Bug ID: 7261
           Summary: Replace Mail::SPF or take ownership of module
           Product: Spamassassin
           Version: 3.4.1
          Hardware: PC
                OS: Windows 7
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Building & Packaging
          Assignee: dev@spamassassin.apache.org
          Reporter: quanah@zimbra.com

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.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 7261] Replace Mail::SPF or take ownership of module

Posted by bu...@bugzilla.spamassassin.org.
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7261

--- Comment #4 from Kevin A. McGrail <km...@pccc.com> ---
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

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 7261] Replace Mail::SPF or take ownership of module

Posted by bu...@spamassassin.apache.org.
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7261

--- Comment #8 from Henrik Krohns <he...@hege.li> ---
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.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 7261] Replace Mail::SPF or take ownership of module

Posted by bu...@spamassassin.apache.org.
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7261

--- Comment #6 from Kevin A. McGrail <km...@apache.org> ---
So this removes any SPF processing from 4.0.0.  So rules like SPF_NONE, etc.
won't work anymore?

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 7261] Replace Mail::SPF or take ownership of module

Posted by bu...@bugzilla.spamassassin.org.
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7261

Henrik Krohns <he...@hege.li> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hege@hege.li

--- Comment #5 from Henrik Krohns <he...@hege.li> ---
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.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 7261] Replace Mail::SPF or take ownership of module

Posted by bu...@spamassassin.apache.org.
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7261

Henrik Krohns <ap...@hege.li> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.0.0                       |Future

--- Comment #9 from Henrik Krohns <ap...@hege.li> ---
Postponing into future, I doubt anyone can tackle this soon

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 7261] Replace Mail::SPF or take ownership of module

Posted by bu...@bugzilla.spamassassin.org.
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7261

Kevin A. McGrail <km...@pccc.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kmcgrail@pccc.com

--- Comment #2 from Kevin A. McGrail <km...@pccc.com> ---
Also see Bug 7224

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 7261] Replace Mail::SPF or take ownership of module

Posted by bu...@bugzilla.spamassassin.org.
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7261

Kevin A. McGrail <km...@apache.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|Undefined                   |3.4.3
           Severity|normal                      |enhancement

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 7261] Replace Mail::SPF or take ownership of module

Posted by bu...@bugzilla.spamassassin.org.
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7261

Benny Pedersen <me...@junc.eu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |me@junc.eu

--- Comment #1 from Benny Pedersen <me...@junc.eu> ---
workaround is to use pypolicyd-spf in mta stage and then in sa reuse headers
from it

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 7261] Replace Mail::SPF or take ownership of module

Posted by bu...@spamassassin.apache.org.
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7261

Henrik Krohns <he...@hege.li> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|3.4.3                       |4.0.0

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 7261] Replace Mail::SPF or take ownership of module

Posted by bu...@spamassassin.apache.org.
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7261

Giovanni Bechis <gi...@paclan.it> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |giovanni@paclan.it

--- Comment #7 from Giovanni Bechis <gi...@paclan.it> ---
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.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 7261] Replace Mail::SPF or take ownership of module

Posted by bu...@bugzilla.spamassassin.org.
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7261

--- Comment #3 from Mark Martinec <Ma...@ijs.si> ---
> 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).

-- 
You are receiving this mail because:
You are the assignee for the bug.