t-verify-self-spf fails without --with-spf; blocks macOS CI

[thegushi]

Summary

t-verify-self-spf always fails unless OpenDMARC is configured with --with-spf. The CI jobs do not pass --with-spf, so this test will fail (not skip) and block the macOS CI job added in #409.

Failure

miltertest: ./t-verify-self-spf.lua: [string "./t-verify-self-spf.lua"]:112: malformed SPF result attached

The test sends a message from trusteddomain.org with an unauthorized IP and expects spf=fail smtp.mailfrom=trusteddomain.org in the Authentication-Results header. With SPFSelfValidate Yes in the filter config, the filter should perform the SPF check. But SPFSelfValidate is gated entirely behind #if WITH_SPF in opendmarc.c, so without --with-spf it is silently ignored and no SPF result is added.

Root cause

opendmarc/tests/Makefile.am includes t-verify-self-spf unconditionally in LIVE_TESTS, but the feature it exercises only works when compiled with --with-spf. It should be gated on TEST_SPF (the autoconf conditional already set by --with-spf).

Fix options

Option A (preferred): gate the test in opendmarc/tests/Makefile.am:

if LIVE_TESTS
check_SCRIPTS += t-verify-multi-from-reject t-verify-multi-from-malformed \
    t-verify-nodata t-verify-nodata-reject \
    t-verify-unspec t-verify-received-spf-good t-verify-received-spf-bad \
    t-verify-authservid-jobid
endif

if TEST_SPF
if LIVE_TESTS
check_SCRIPTS += t-verify-self-spf
endif
endif

Option B: add --with-spf to the CI configure commands. libspf2 is not required -- passing --with-spf alone (without --with-spf2-include/--with-spf2-lib) enables the internal opendmarc_spf_test() implementation already compiled into libopendmarc. libspf2 is not available in Homebrew, so this is also the only practical path on macOS.

Both options are compatible and complementary.

[thegushi]

Additional context: the internal SPF implementation (opendmarc_spf.c / opendmarc_spf_dns.c) is under active consideration for removal from libopendmarc. That makes Option B (using --with-spf without libspf2) a dead end for CI regardless -- it would be testing code that may not exist in a future release.

Option A (gate the test on TEST_SPF) is the right fix. If libspf2 CI coverage is wanted later, it can be added when the internal implementation is actually removed and libspf2 is the only path.