Refer to bug 1406939 for description - issue is present in both python-pyspf and pypolicyd-spf. Also equal to bug 1232595 (and related bug 1230373) in Fedora.
That switch was entirely on purpose, actually. Long term plan is to switch to python3 (already done in Fedora). I contacted maintainer of python-pyspf to do this for EPEL, but got no response yet.
It appears that a new pypolicy-SPF package was built on 2nd October with a dependancy change and pushed to EPEL-7 in the last week or so. After doing a simple "yum update" on a bunch of mail servers, all of them had complete mail failure due to the issues on bug 1406939. Oct 28 10:46:30 localhost postfix/smtpd[3701]: NOQUEUE: reject: RCPT from mailserver.com[xx.xx.xx.xx]: 451 4.3.5 Server configuration problem; from=<foo> to=<bar> proto=ESMTP helo=<remotemailserver.com> [root@mail ~]# rpm -qi pypolicyd-spf | grep -E 'Build|Version' Version : 1.3.2 Build Date : Mon 02 Oct 2017 23:33:00 BST Build Host : buildvm-29.phx2.fedoraproject.org I understand the reason for moving to python3 eventually, but this change could cause a lot of issues. Can this new package be removed from the repo? [root@mail SPECS]# grep -E '^Version|^Release|^Requires' pypolicyd-spf.spec Version: 1.3.2 Release: 1%{?dist} Requires: postfix, python-pyspf, python-ipaddr [root@mail SPECS]# grep -E '^Version|^Release|^Requires' pypolicyd-spf.spec Version: 1.3.2 Release: 2%{?dist} Requires: postfix, python-pyspf, python-ipaddress
I know it sucks, but stable updates cannot be unpushed. I asked for commit access to python-pyspf, which is where the problem is and I'm planning to fix that. It will take a while to get it to stable though. Just like pypolicyd-spf, the python-pyspf will have to be in testing for a couple of weeks before it gets pushed to stable. Will keep you posted.
See https://bugs.centos.org/view.php?id=12393#c30486 for possible immediate removal of unnecessary dependency. Thanks a lot.
pypolicyd-spf-1.3.2-3.el7 python-pyspf-2.0.11-4.el7 has been submitted as an update to Fedora EPEL 7. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-aded0ed528
I tried the pypolicyd-spf and python-pyspf updates from koji and they do not fix this.
(In reply to Chris Adams from comment #7) > I tried the pypolicyd-spf and python-pyspf updates from koji and they do not > fix this. These do not show dependency on ipaddress: https://koji.fedoraproject.org/koji/rpminfo?rpmID=11907608 https://koji.fedoraproject.org/koji/rpminfo?rpmID=11907606
RPM doesn't auto-generate python dependencies (at least on EPEL 7). In python-pyspf-2.0.11-4.el7.noarch, /usr/lib/python2.7/site-packages/spf.py line 103 tries the ipaddress module, and only loads ipaddr if that fails. Anyone that has install the RPM with the explicit python-ipaddress already has that module installed, so the updated python-pyspf will still use it. You need to actually patch out the ipaddress module load to get ipaddr.
Could you please try: https://koji.fedoraproject.org/koji/buildinfo?buildID=992735 https://koji.fedoraproject.org/koji/buildinfo?buildID=992734
Not good after yum localupdate python-pyspf-2.0.11-5.el7.noarch.rpm yum localupdate pypolicyd-spf-1.3.2-4.el7.noarch.rpm and reboot: +++++++ Nov 1 10:56:52 mgate postfix/smtpd[1053]: Anonymous TLS connection established from mail.abc.tld[11.22.33.44]: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits) Nov 1 10:56:52 mgate postfix/spawn[1058]: warning: command /usr/libexec/postfix/policyd-spf exit status 1 Nov 1 10:56:52 mgate postfix/smtpd[1053]: warning: premature end-of-input on private/policyd-spf while reading input attribute name Nov 1 10:56:53 mgate postfix/spawn[1058]: warning: command /usr/libexec/postfix/policyd-spf exit status 1 Nov 1 10:56:53 mgate postfix/smtpd[1053]: warning: premature end-of-input on private/policyd-spf while reading input attribute name Nov 1 10:56:53 mgate postfix/smtpd[1053]: warning: problem talking to server private/policyd-spf: Connection reset by peer Nov 1 10:56:53 mgate postfix/smtpd[1053]: NOQUEUE: reject: RCPT from mail.abc.tld[11.22.33.44]: 451 4.3.5 Server configuration problem; from=<...> to=<...> proto=ESMTP +++++++ No python-ipaddress package installed Previous packages pypolicyd-spf-1.3.2-3.el7.noarch.rpm python-pyspf-2.0.11-4.el7.noarch.rpm work fine.
I think I messed up that patch. Could you please try: https://kojipkgs.fedoraproject.org//packages/pypolicyd-spf/1.3.2/5.el7/noarch/pypolicyd-spf-1.3.2-5.el7.noarch.rpm
After yum localupdate pypolicyd-spf-1.3.2-5.el7.noarch.rpm python-pyspf-2.0.11-5.el7.noarch.rpm everything looks ok both with and without installed package python-ipaddress (from base repo) Thanks
(In reply to Petr_P from comment #13) > After > > yum localupdate pypolicyd-spf-1.3.2-5.el7.noarch.rpm > python-pyspf-2.0.11-5.el7.noarch.rpm > > everything looks ok both with and without installed package python-ipaddress > (from base repo) Thanks for testing. Once bodhi unlocks epel7 repo, I'll edit the update and submit those packages instead.
pypolicyd-spf-1.3.2-3.el7, python-pyspf-2.0.11-4.el7 has been pushed to the Fedora EPEL 7 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-EPEL-2017-aded0ed528
pypolicyd-spf-1.3.2-5.el7 python-pyspf-2.0.11-5.el7 has been submitted as an update to Fedora EPEL 7. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-aded0ed528
pypolicyd-spf-1.3.2-5.el7, python-pyspf-2.0.11-5.el7 has been pushed to the Fedora EPEL 7 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-EPEL-2017-aded0ed528
pypolicyd-spf-1.3.2-5.el7, python-pyspf-2.0.11-5.el7 has been pushed to the Fedora EPEL 7 stable repository. If problems still persist, please make note of it in this bug report.