spfquery -> libspf2

[Robert Millan]

Hi,

I'd like to switch from spfquery to libspf2 for SPF handling.  To get into
context, I first checked what we have in the FAQ [1].  It seems that initially,
we chose to use spfquery because:

> # Calling spfquery is a reliable method, because it's the most transparent and easy to debug.
>   It is also the method we have tested more throughfuly and are most experienced with.
> # We do not want to drag in another library dependency. That would add more potential for
>   bugs and maintenance work than a configuration snippet that is disabled by default.
> # We haven't verified that all the features of spfquery are available using built-in
>   support as well (in particular, support for X-SPF-Guess header, or the hability to add
>   user extensions that rely on the same checks).

... however, with time this has changed.  In June 2007 I setup a production
server to use libspf2, and spent a while hacking on it and sanitizing it
(patches 40_permanent_include_errors.dpatch, 41_none_not_neutral.dpatch and
42_empty_sender.dpatch in libspf2 package are the result of this work).

During that period I also implemented support in upstream Exim package for SPF
"best guess" feature (http://bugs.exim.org/show_bug.cgi?id=521).

I think at this point I can fairly say that:

  - I'm more familiar with libspf2 method (both from Exim side and libspf2
    itself) than with libmail-spf-query-perl (issue #1).

  - exim4 with libspf2 is quite robust.  I've had this setup for more than 6
    months now, and after fixing the initial problems in libspf2, nothing new
    arised (issue #2).

  - All the features are there now:  "best guess" was missing, which I
    implemented and will be there in next upstream release;  user extensions
    are supported using the standard semantics (I must have been confused about
    this one) (issue #3).

Additionally, other advantages exist:

  - ACL conditions are simple and easier to work with (e.g. "spf = fail" and
    so);  specially important when users want to grab them as example to do
    something else.

  - Eats less CPU (C instead of perl, preloaded instead of fork/exec for every
    check).

So what do you think?  If there's no objection, I'd like to do the migration.

As for the upstream part (for "best guess"), I'd prefer patching the source
for it, but waiting untill next release is fine with me either.

[1] http://wiki.debian.org/PkgExim4UserFAQ#head-5d10255cb75e876c4fb886aa5adeeca577554f5b

-- 
Robert Millan

<GPLv2> I know my rights; I want my phone call!
<DRM> What use is a phone call… if you are unable to speak?
(as seen on /.)