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

Just provide a DKIM only mechanism/option.

Michael Hammer

On Sat, Feb 23, 2019 at 2:56 PM Kurt Andersen (b) <kboth@drkurt.com> wrote:

> On Sat, Feb 23, 2019 at 11:00 AM Hector Santos <hsantos@isdg.net> wrote:
>
>> On 2/23/2019 1:07 PM, Kurt Andersen (b) wrote:
>> >
>> > 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?
>> >
>>
>> it shouldn't matter it its huge or tiny, the protocol applies equally.
>>
>
> Quite so - however, some of the mechanisms and common usage patterns do
> differ depending on the scale and complexity of the sender asserting the
> record.
>
>
>> It helps to use an example. For example:  gmail.com has: [redirect
>> elided]
>>
>> 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.
>>
>
> Note that terminal "all" mechanisms are ignored in the handling of the
> include evaluation (RFC7208 section 5.2).
>
>
>> it sounds like you are proposing an include prefix result should override
>> matching result, including the default/final result.
>
>
> No, I'm suggesting that the neutral mechanism prefix should be promoted as
> a "better way" to cite includes of large common sending platforms. "Better"
> than the default pass evaluation 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.
>>
>
> Not an override - just a different result.
>
>
>> 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 think that the biggest problem with nested includes (I'm intentionally
> avoiding the "recursion" term because it should not be recursive or
> circular) is the table in RFC7208 section 5.2 which asserts that a neutral
> result from check_host ends up being treated as a "not-match" condition.
> The way I read that is that if d1.example has ?include:d2.example which in
> turn has a ?include:d3.example, then a check_host match on the d3.example
> record would not end up percolating up to d1.example as a neutral final
> result.
>
> --Kurt
> _______________________________________________
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>