I have become persuaded to Scott's approach, as long as it is documented clearly.
For DMARC-enabled evaluators: - auth=DKIMOnly requires that the domain owner have high confidence that every message source is applying DKIM signatures. - ?include=hostingservice only requires knowledge that one particular message source has implemented DKIM signatures. Because certainty can be hard to achieve, the requirement for 100% participation may be a significant obstacle. ?include allows the rule to be applied tactically where needed (on multi-tenant hosting services) and bypassed elsewhere (when SPF upgrade is not a concern). For SPF-only evaluators: I have some experience with four different SPF-only products, and in each case, when the SPF test is enabled, the disposition is "block on SPF FAIL, allow on any other result". Therefore I think the risk is low that a change from PASS to NEUTRAL will actually cause legitimate messages to be blocked. In sum, no expected impact on SPF-only evaluators, and immediate SPF Upgrade protection for evaluators that are compliant with both SPF and DMARC specifications. Doug Foster On Sun, Oct 29, 2023 at 9:44 AM Richard Clayton <rich...@highwayman.com> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > In message <CAAFsWK2pezgeYKDM=4ggbcfpquk_yewpkdcfm0j3s9eod5r...@mail.gma > il.com>, Wei Chuang <weihaw=40google....@dmarc.ietf.org> writes > > >I don't think the SPF '?' qualifier approach works because as Richard > >Clayton said earlier of RFC7208 "Sender Policy Framework (SPF) for > >Authorizing Use of Domains in Email, Version 1" section 8.2 which says: > > > > A "neutral" result MUST be treated exactly like the "none" result; > > the distinction exists only for informational purposes. > > Scott pointed out that I had not understood it correctly ... when you > run a matching sending IP against a "?" mechanism then you get "neutral" > which you are obliged to treat as "none". But you stop there. > > When you run a non-matching sending IP against that same "?" mechanism > then you get a "fail" so you keep on going to look at all the other > mechanisms (which also all fail) and eventually (in practice) reach > "-all" or "~all" at the end of the record. > > hence you can still use SPF to filter out the non-starters, but you > don't get any warm and fuzzy feeling from the pass... > > So the SPF publisher they can either publish "?" information or nothing > at all -- and the _only_ reason for doing the former is to help with an > initial filtering mechanism at sites that use SPF for that purpose. > > >If it happens to work, it's likely an implementation detail not > >standardized across the ecosystem and may change. > > You're right that there's no way of knowing whether the people who are > currently paying a lot of attention to SPF (and less so to DKIM) are > going to make poorer decisions when what used to be an SPF pass now > becomes a "none" result. > > Allowing DKIM-only to be specified in DMARC allows people to still > publish SPF records that yield a pass (thus generating a (possibly > mistaken) warm and fuzzy feeling in some quarters ...) > > >Moreover it will be > >highly confusing to those outside of those with connection to the > >knowledgeable few. That broader community depends on the literal > >interpretation of the RFC. > > That's what still confuses me about the objections to the proposal to > explicitly allow people to say "DKIM only". > > Yes I get that it adds a little bit to the text of the document and > requires a bit more code to parse the new parameter and hence you can > object on the basis of "complexity" -- but it does seem simpler to > understand the stricture "ignore SPF" than grok the necessity to alter > SPF records to use a complex-to-understand mechanism which may degrade > some deliverability. > > - -- > richard Richard Clayton > > Those who would give up essential Liberty, to purchase a little temporary > Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755 > > -----BEGIN PGP SIGNATURE----- > Version: PGPsdk version 1.7.1 > > iQA/AwUBZT5hO92nQQHFxEViEQIM0gCfU3ZV3bEfi9kAfEFThr+30GJWqFsAoI2z > xh0KGaaD5mELlRimHgVMwRDu > =HmrF > -----END PGP SIGNATURE----- > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc >
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
