Use of "+all" and "?all" in SPF record negating purpose of SPF record #140
Labels
breaking change
This issue or pull request involves changes to existing functionality
improvement
This issue or pull request will add or improve functionality, maintainability, or ease of use
need info
This issue or pull request requires further information
💡 Summary
I observe that
trustymail
does not flag the use of+all
,?all
, or absence of theall
mechanism in a non-redirected SPF record when its use is syntactically valid; however, its use often negates the purpose of having an SPF record.Motivation and context
Why does this work belong in this project? The purpose of BOD 18-01, in part, is to decrease the possibility of unauthorized emails from appearing to originate from .gov domains. When an organization uses the pass
+
qualifier on theall
mechanism, any server can send email on behalf of (i.e., impersonate) the organization's domain. Similarly, the neutral?
qualifier on theall
mechanism is equivalent to having no SPF record (except for domains matched via mechanisms preceding theall
mechanism).This would be useful because... we want the SPF record to serve its intended purpose rather than just filling a compliance placeholder.
Implementation notes
+
qualifier is automatically prepended (section 4.6.2).?all
at the end of every SPF record (section 4.7).all
mechanism are ignored and are thus ineffective and meaningless (section 5.1).all
mechanism and aredirect
modifier, theredirect
modifier is ignored (section 5.1).+all
. For example, the SPF record could contain-ip4:
mechanisms to cause all of the IPv4 address space to fail except for its own domain's address space. Because this seems like a highly unlikely approach, I do not consider it here, except to mention it as a possibility.trustymail
SPF validation work actually occurs inpyspf
, this issue might be more appropriately implemented there. On the other hand, these records are syntactically valid but semantically invalid (i.e., just poorly implemented) so perhaps accounting for these discrepancies would be better here intrustymail
. Regardless, I report this issue here because of its ramifications ontrustymail
's validity in thattrustymail
's operators could trust that they have good SPF records when their SPF records do not actually serve their intended purpose.Acceptance criteria
+all
,?all
, or the implicit?all
.trustymail
as is;pyspf
; orReferences
All references are from RFC 7208 unless otherwise cited.
+
,-
,~
, and?
), see section 4.6.2.all
mechanism, see section 5.1.The text was updated successfully, but these errors were encountered: