Just provide a DKIM only mechanism/option. Michael Hammer
On Sat, Feb 23, 2019 at 2:56 PM Kurt Andersen (b) <[email protected]> wrote: > 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 >
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
