On Sat, Feb 23, 2019 at 11:00 AM Hector Santos <[email protected]> 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 [email protected] https://www.ietf.org/mailman/listinfo/dmarc
