Make libspf2 a hard dependency; remove internal SPF implementation

[thegushi]

Summary

The internal SPF implementation in libopendmarc/opendmarc_spf.c (compiled when libspf2 is not present) has several known compliance gaps relative to RFC 7208. We believe libspf2 should be a hard build dependency and the internal fallback should be removed.

Known failure modes in the internal implementation

1. Void lookup limit not enforced (RFC 7208 §4.6.4)

RFC 7208 requires that void DNS lookups — queries that return NXDOMAIN or empty results — be limited to 2 separately from the overall 10-lookup cap. The internal implementation tracks total lookups (MAX_SPF_DNS_LOOKUPS) but has no void lookup counter. A domain with a pathological SPF record can cause more void lookups than the spec permits, leading to divergent results from a compliant evaluator.

2. Multiple SPF TXT records not detected (RFC 7208 §3.2)

If a domain publishes more than one v=spf1 TXT record, the result MUST be permerror. The internal DNS layer (opendmarc_spf_dns.c) returns the first matching TXT record and silently ignores any subsequent ones. A domain with duplicate or conflicting SPF records will be evaluated rather than returning permerror, potentially producing a pass where a conformant evaluator would refuse to evaluate.

3. IPv4-mapped IPv6 addresses (RFC 7208 §5)

When a sender connects over IPv6 with an IPv4-mapped address (::ffff:192.0.2.1), SPF evaluation should use the IPv4 address and mechanisms. The code contains comments acknowledging uncertainty about this mapping ("we don't care at this point if it is ipv6 or ipv4"), suggesting this case is not reliably handled.

4. Dual CIDR-length notation (RFC 7208 §5.6, §5.7)

The a and mx mechanisms support a dual CIDR notation (a/24//48) specifying separate prefix lengths for IPv4 and IPv6 matches. Incorrect or absent handling here produces wrong pass/fail results for affected records.

Why libspf2 should be required

libspf2 is a dedicated SPF implementation with years of real-world testing and bug fixes across all of the above cases. Maintaining a parallel SPF implementation inside OpenDMARC duplicates that effort poorly. The internal fallback also creates a situation where two installations of OpenDMARC with identical configuration can produce different DMARC verdicts depending on whether libspf2 happened to be present at build time — which is a hard problem to diagnose in production.

The HAVE_SPF2_H conditional should become a hard build requirement, and the #else branch should be removed.

We would welcome a patch to do this, or to at minimum make ./configure fail with a clear error when libspf2 is absent and SPFSelfValidate support is requested.

[Neustradamus]

@thegushi: libspf2 is not currently developed, I have created several tickets to relaunch the development:

• A new team for this project? shevek/libspf2#59
• Transfer this repository into another place (organization) shevek/libspf2#58

[thegushi]

@thegushi: libspf2 is not currently developed, I have created several tickets to relaunch the development:

• A new team for this project? shevek/libspf2#59
• Transfer this repository into another place (organization) shevek/libspf2#58

Oh good, so I'm not the only open source contributor dealing with the patented Neustradamus brand of "open a bunch of tickets in EVERY repo and complain but don't actually push any code, tests, or reproductions?" Or piling on when they fix one thing and pointing "hey, hey, what about this! DEAD PROJECT! DEAD PROJECT! WHAT ABOUT YOUR WEBSITE! WHAT ABOUT YOUR BOARD MEMBERS!"

Seriously, it's a great way to get banned, and help contribute to developer burnout. You're not helping. If you want to help, tell me about your skillsets and we'll have a conversation.

As things stand, libspf2 is (as covered above), a better fit and more feature complete against the existing spec, and it's at a mostly stable state. If there needs to be a community fork of that in its own time, that can happen.

I would rather not have two difficult to maintain SPF implementations out in the world, especially when they behave differently with weird cases like lots of macros and includes (which happen more and more with all the SAAS companies that make it hard to flatten your records).

SPF already annoys me for a couple of reasons (the whole TXT/SPF/No wait actually we're back to TXT) debacle, the decision to use an apex domain (example.com TXT "foo") versus a sublabel (_spf.example.com TXT "foo"), plus the arbitrary limits I just mentioned, which, for people who are just told "paste this into your zone and it will work" will burn them because they didn't read the RFCs and don't grok DNS.

...but hey, at least it doesn't require putting up an https webpage to publish your policy.

[Neustradamus]

@thegushi: Why do you mix all? :/

Here, I only inform you about the libspf2 situation, I do not speak about the The Trusted Domain Project situation.
I have not said you that the libspf2 is bad, only that there is not a development and I have contacted the author to move this project in an organization and to add new team members to a new developement.

About The Trusted Domain Project, there are already different tickets in different repositories.
Yes, I have requested a new team members in this organization to have a new developement like different people have specified on the Web that, badly, the different softwares have not been updated since several years.
I always try to help projects to realive...

[thegushi]

@thegushi: Why do you mix all? :/

Why do you post about the website and the board and https in the software repos? If you can do that, so can I.

Here, I only inform you about the libspf2 situation, I do not speak about the The Trusted Domain Project situation. I have not said you that the libspf2 is bad, only that there is not a development and I have contacted the author to move this project in an organization and to add new team members to a new developement.

It's exactly the same behavior. "Here, look, I'm not just irritating you by opening 5 issues with the same text in 5 different repos, I'm pointing out where I'm doing it to another project."

And then, as soon as I mention our mailing lists, you're over telling people that a patch I've submitted to JaredMauch's mailman2-python3 repo has been merged. (Thanks, Github already tells them that). It's a little creepy, and I'm calling it out.

I always try to help projects to realive...

Your definition of "help" is subjective.

Developer burnout is an absolute thing.

Many times, people were paid to write this software but are not being paid on an ongoing basis to maintain it, so for me and people like Futatuki, this is something we need to do for our day job to keep our own stuff running, but that's a very different thing than triaging all the bugs on every platform.

People have lives that change and often do open source implementations that aren't quite perfect, because then people do things in the real world that are beyond the original spec. (Look at this repo, for example, and how ARC adoption by MS and Goog have caused more failures in OpenDMARC with ARC specifically.) It was written when the RFC's were new (or even, were I-D's), and real-world use cases (in not always compliant ways) exposed the issues.

People are running this stuff on platforms it was not developed or tested on, and local OS packagers are making changes downstream that the users don't know about, so they're invisible to us who will test with the source code.

SPF is another such example, actually. It was pushed for use before the RFCs were finalized, and ultimately, like DomainKeys and DKIM, and even DMARC, it was not the great end-all solution that was promised.

Which itself is a reason for burnout.

===

And if you want to see what a worst-case-scenario for developer burnout looks like: Go look at the xz utils story. Someone "helpfully" came in to help on a dying project where the dev was struggling, and contributed for years, only to slip one of the worst trojans in recent history in.

And ironically, Jia Tan was probably paid better than most open-source contributors for their work.

There's a reason there's skepticism in open source projects.

[Neustradamus]

@thegushi: Badly, I know the XZ story, since several years, I announce the release software versions in the World and I have announced the impacted version. After it, a Microsoft researcher has found the XZ vulnerability.