fix(spf): expand %{d} macro to the domain currently being evaluated - #126
Merged
Conversation
Previously %{d} always expanded to the sender domain, behaving exactly
like %{o}. Inside included or redirected SPF records the macro must
expand to the domain whose record is currently being evaluated by
check_host() (RFC 7208 sections 5.2, 6.1 and 7.2), so nested records
using %{d}, and the bare ptr mechanism, built DNS lookups against the
wrong domain and caused spurious permerrors.
Refs #125
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GLXjjgoCN1dJsRqc9R98gu
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
RFC 7208 defines
das the current<domain>of check_host(), which changes on everyinclude:/redirect=recursion, whileostays on the sender domain (sections 5.2, 6.1, 7.2, 7.3). mailauth expanded%{d}as an alias of%{o}, so macros inside nested SPF records were built from the wrong domain, producing bogus DNS lookups and spurious permerrors, as reported in #125.Changes:
lib/spf/macro.js:dnow expands from a new optionalvalues.domain(falling back to the sender domain, which is the correct top-level value),oandpkeep using the sender domainlib/spf/spf-verify.js: eachspfVerify()recursion level passes its owndomainto every macro expansion site; the bareptrmechanism now uses the current domain directly%{d}expansion mirroring the reported chain (asserting the wrong hostname is never queried),%{d}afterredirect=,%{o}staying on the sender in nested includes, and macro unit tests. All three%{d}tests fail on master and pass with this fix; the full suite (756 tests, including the RFC 7208 test suite) passes.