On March 21, 2017 1:51:10 PM EDT, "James B. Byrne" <byrn...@harte-lyne.ca> wrote: >I am re-provisioning the host system that lost its HDD last week and >am taking the opportunity to install FreeBSD. This system will host >our off-site MX and DNS services. In the process of installing >postfix-3.1.4 I have run across a package named postfix-policyd-sf. >On cursory inspection this appears to be a drop in replacement for >both postgrey and policyd-spf.
I'm probably not the best one to do a point by point comparison, since I wrote one of the alternatives. I did, however, take a quick look and postfix-policyd-sf seems somewhat under-maintained. The last non-development release I found was from 2009. Tumgreyspf is another one that does both SPF and grey listing. >As policyd-spf does not appear to be provided via the FreeBSD ports >collection I am contemplating using postfix-policyd-sf instead as this >is provided as a binary package. Since postfix-policyd-sf reputedly >handles the postgrey service its use would eliminate postgrey as a >separate maintenance item as well. > >postfix-policyd-sf has a dependency on libmysqlclient.so.18 and so I >infer that there is a mySQL/MariaDB database somewhere as the >back-end. However, there is no information provided as to how this is >to be set up, configured or maintained if such a requirement exists. > >Before I do anything rash I would like to receive any comments anyone >may have respecting replacing postgrey and policyd-spf with >postfix-policyd-sf. Are there configuration issues? Is >postfix-policyd-sf less flexible in handling white-listing senders? >Is mySQL a requirement? > >Thanks, > >P.S. > >The problems last week that we had with policyd-spf were tied to the >loss of one of our DNS services. The resolver on the MX host was >slightly misconfigured which exacerbated the delay in reaching a >responding server. However, the local host (127.0.0.1) was at the top >of the list in resolv.conf and it was providing DNS service without >any appreciable delay so I cannot fathom why policyd-spf was looking >elsewhere. Based on that, I know what the problem was. There's no internal mechanism in my policyd-spf to do DNS lookups. Those are handled by pydns (or py3dns if running with python3). There is a rather annoying pydns bug where lookups fail if any resolver fails (yes, the exact opposite of what you want). I have developed a fix and sent it upstream, but they have not done a new release. I patched it in Debian (and thus derivatives) a long time ago, but being on a Red Hat derived system, you probably don't have the fix. Py3dns does not suffer from the same issue. Switching to the current version of my policy server (2.0.1) as well as current versions of pyspf and py3dns should resolve the fragility you saw due to what should have been a minor problem. Scott K
