Re: [dmarc-ietf] Should we encourage the use of SPF "soft include" for common platforms?

[Hector Santos <[e-mail]>]

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