Bug 1399246

The script is included as an example of using the module, in the documentation directory, not in /usr/bin as fully supported tool. That's why the executable bit is explicitly disabled. Closing as NOTABUG, please reopen if you disagree.

If you use google to search for solutions to check SPF with mailservers, this script is mentioned on so many pages and examples, as the final solution to the problem. Not one page suggests, that it is an example, and neither does the programm itself look like an example.

The commentsection of the script does not mention it too, so ..

yes, i disgree and this script should be useable systemwide.


# 
# spfquery: Command-line tool for performing SPF queries
#
# (C) 2005-2012 Julian Mehnle <julian>
#     2004      Wayne Schlitt <wayne>
# $Id: spfquery 138 2006-01-22 18:00:34Z julian $
#

Various web pages are independent from how things are packaged in Fedora and why, so they cannot really comment on perl-Mail-SPF package layout.

So it looks like you are really asking for something else -- you ask to have the script shipped in location where executable commands typically live, and supported as such in Fedora.

Let us see what Steven who initially packaged the module thinks. Steven, would you remember the reason behind packaging spfquery and spfd as documentation in the initial packaging of perl-Mail-SPF?

   http://pkgs.fedoraproject.org/cgit/rpms/perl-Mail-SPF.git/tree/perl-Mail-SPF.spec#n163

I wasn't aware of this package logic. Yes, please move it to ..sbin/ and change the filemods to 755. 

As it does not need to have SUID rights to be used, should not be a problem. I also suggest to set a symlink at the old spot, so that existing serversetups are not broken by this change.

I don't think it belongs to /usr/sbin, it's a normal user-space, so it should go to /usr/bin. And here we have a problem because /usr/sbin/spfquery is already implemented by python-pyspf.

I don't have this installed, so in my case this would not be problem.

But as many packages have this situation, like exim and postfix emulating sendmail, we could use the /etc/alternatives/.. Symlink schema to decide which gets used in the end.

It's also provided by libspf2, and *that* already uses alternatives.

(In reply to Paul Howarth from comment #7)
> It's also provided by libspf2, and *that* already uses alternatives.

I took a look at libspf2-1.2.10-8.20150405gitd57d79fd.fc25.x86_64 but that does not seem to ship any binary (program), just library:

# rpm -ql libspf2
/usr/lib64/libspf2.so.2
/usr/lib64/libspf2.so.2.1.0
/usr/share/doc/libspf2
/usr/share/doc/libspf2/INSTALL
/usr/share/doc/libspf2/README
/usr/share/doc/libspf2/TODO
/usr/share/licenses/libspf2
/usr/share/licenses/libspf2/LICENSES

It's in the libspf2-progs sub-package.

perl-Mail-SPF-2.9.0-12.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2017-b7b0662978

The new build contains spfquery and spfd as alternatives. I'd appreciate your feedback.

Sorry it took me so long to get into packaging it.

perl-Mail-SPF-2.9.0-12.fc26 has been pushed to the Fedora 26 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-b7b0662978

perl-Mail-SPF-2.9.0-12.fc26 has been pushed to the Fedora 26 stable repository. If problems still persist, please make note of it in this bug report.

The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days