I observe that trustymail does not flag the use of +all, ?all, or absence of the all 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 the all mechanism, any server can send email on behalf of (i.e., impersonate) the organization's domain. Similarly, the neutral ? qualifier on the all mechanism is equivalent to having no SPF record (except for domains matched via mechanisms preceding the all 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
When no qualifier is specified on a mechanism, the default + qualifier is automatically prepended (section 4.6.2).
There is an implicit ?all at the end of every SPF record (section 4.7).
Any mechanisms appearing after the all mechanism are ignored and are thus ineffective and meaningless (section 5.1).
In any SPF record containing both an all mechanism and a redirect modifier, the redirect modifier is ignored (section 5.1).
There is a possibility that a good SPF record contains +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.
Because the vast majority of trustymail SPF validation work actually occurs in pyspf, 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 in trustymail. Regardless, I report this issue here because of its ramifications on trustymail's validity in that trustymail's operators could trust that they have good SPF records when their SPF records do not actually serve their intended purpose.
Acceptance criteria
[ ] First, we need to know CISA's desires for whether to mark an SPF record as invalid when it contains +all, ?all, or the implicit ?all.
Based on this desire, we can:
[ ] Leave trustymail as is;
[ ] Report this issue on pyspf; or
[ ] Apply the changes according to CISA's desires.
References
All references are from RFC 7208 unless otherwise cited.
For the qualifiers (+, -, ~, and ?), see section 4.6.2.
💡 Summary
I observe that
trustymaildoes not flag the use of+all,?all, or absence of theallmechanism 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 theallmechanism, any server can send email on behalf of (i.e., impersonate) the organization's domain. Similarly, the neutral?qualifier on theallmechanism is equivalent to having no SPF record (except for domains matched via mechanisms preceding theallmechanism).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).?allat the end of every SPF record (section 4.7).allmechanism are ignored and are thus ineffective and meaningless (section 5.1).allmechanism and aredirectmodifier, theredirectmodifier 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.trustymailSPF 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.trustymailas is;pyspf; orReferences
All references are from RFC 7208 unless otherwise cited.
+,-,~, and?), see section 4.6.2.allmechanism, see section 5.1.