postfix-policyd-sf vs. policy-spf + postgrey

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

postfix-policyd-sf vs. policy-spf + postgrey

James B. Byrne
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.

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.


--
***          e-Mail is NOT a SECURE channel          ***
        Do NOT transmit sensitive data via e-Mail
 Do NOT open attachments nor follow links sent by e-Mail

James B. Byrne                mailto:[hidden email]
Harte & Lyne Limited          http://www.harte-lyne.ca
9 Brockley Drive              vox: +1 905 561 1241
Hamilton, Ontario             fax: +1 905 561 0757
Canada  L8E 3C3

Reply | Threaded
Open this post in threaded view
|

Re: postfix-policyd-sf vs. policy-spf + postgrey

Scott Kitterman-4


On March 21, 2017 1:51:10 PM EDT, "James B. Byrne" <[hidden email]> 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