On 2/23/2019 1:07 PM, Kurt Andersen (b) wrote:
With the growth of huge platforms that emit mail from the same common set
of IPs (such as GSuite, O365, or large ESPs), regular SPF "include" ends up
granting a DMARC pass to a lot more potential authors than most
organizations would necessarily choose to grant.
Instead of using the standard "(+)include:" approach, if domain owners used
"?include:" as their mechanism, then that would prevent the SPF result from
granting a DMARC PASS result when traffic is coming from one of these
massively included platforms. It would essentially force the DMARC result
to be driven only by the DKIM evaluation.
Thoughts?
Kurt,
In general, in the name of cooperative competition, I am *always* in
favor of a protocol "standard" that applies to all scales. So it
shouldn't matter it its huge or tiny, the protocol applies equally.
It helps to use an example. For example: gmail.com has:
v=spf1 redirect=_spf.google.com
which returns:
v=spf1 include:_netblocks.google.com include:_netblocks2.google.com
include:_netblocks3.google.com ~all
The SPF processor result SHOULD be based on each one. In this case,
each include results in a softfail (~all) when there is no match.
Keeping in mind the recursive complexity that can occur here with
multiple layers of includes, it sounds like you are proposing an
include prefix result should override matching result, including the
default/final result. So for example, using one the includes for
gmail.com:
v=spf1 include:_netblocks.google.com include:_netblocks2.google.com
?include:_netblocks3.google.com ~all
where you want to override the results of _netblock3 with a neutral
result rather than use the matching result or final/default result of
the specific include.
Unless the conditions were limited to when this can be applied, I can
see where this can become really complex because of higher recursion
potentials. You also have compatibility concerns as well.
I have to recheck to how my legacy platform SPF code is designed for
such a recursive include result override "change request" but is this
what you are basically asking for here?
--
HLS
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
