The intended purpose of using it in the referenced scenario is to avoid the negative connotation of ~ or - on their shared infrastructure mechanism(s) in SPF evaluation, while also producing a non-pass for SPF to DMARC.
Many receivers use the failure SPF results as additional signals to spam/junk filtering; if a sender used the latter two (~ or -) instead of neutral (?), it would only cause more issues. But as you stated, I agree the handling of the neutral qualifier is most likely non-standardized across the internet. - Mark Alley On Sun, Oct 29, 2023, 1:39 AM Wei Chuang <weihaw=40google....@dmarc.ietf.org> wrote: > 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. > > If it happens to work, it's likely an implementation detail not > standardized across the ecosystem and may change. 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. > -Wei > > On Sat, Oct 28, 2023 at 3:58 PM Mark Alley <mark.alley= > 40tekmarc....@dmarc.ietf.org> wrote: > >> For the shared provider SPF upgrade example, I think Scott's previously >> mentioned method of using SPF '?' qualifier on the relevant shared >> mechanism mitigates the upgrade problem, and ensures only DKIM can provide >> passing authentication. >> >> Thinking back earlier this year to the well-publicized SPF upgrade >> vulnerability of a certain vendor, many affected senders mitigated it until >> fixed by the vendor by utilizing the aforementioned neutral ? qualifier >> method to great effect. >> >> Do we really need this when existing protocol methods of mitigating SPF >> upgrades already exist? >> >> This is basically like painting a potato red, and calling it a tomato. It >> still tastes like a potato. >> >> -Mark Alley >> >> On Sat, Oct 28, 2023, 3:04 PM Emanuel Schorsch <emschorsch= >> 40google....@dmarc.ietf.org> wrote: >> >>> As to why, I don't think there's a valid use case and the proponents for >>>> this haven't really thought it through. As an example, someone (I don't >>>> recall who) cited the issue of domain owners that publish SPF, but can't be >>>> bothered to set up DKIM. The implication is that this minimum effort >>>> domain owner will read DMARCbis when it comes out and decide to update >>>> their records as a result with the new tag. I don't think that's very >>>> realistic. >>>> >>>> So who would use this tag then? >>>> >>>> It would have to be a domain owner which publishes an SPF record that >>>> enables spoofing their domain, understands SPF and DMARC well enough to >>>> know that is a concern for DMARC and yet simultaneously doesn't know how to >>>> fix their SPF record and does know about this new tag. >>>> >>>> I don't think that person exists. At best this new tag is some kind of >>>> security theater. >>>> >>> >>> Thanks for that clarification! I think I can clear up what the specific >>> use case is. It's to deal with SPF Upgrade. Assume we have a domain, ` >>> business.com`, that has properly set up SPF and DKIM and uses a shared >>> provider and so includes the relevant provider IPs in their SPF record. >>> They have a DMARC p=reject policy. But, unfortunately, the shared provider >>> they use is vulnerable to SPF upgrade and so there have been successful >>> upgrades allowing a spammer / phisher to achieve a `business.com` SPF >>> pass. Notably, this does not allow the spammer to achieve a ` >>> business.com` DKIM pass. Today, this will be a DMARC pass (because of >>> the SPF), and it is not always so easy for downstream receivers to know >>> there has been an upgrade. >>> >>> Take the above example, and imagine we've added an `auth=dkim` tag >>> option. `business.com` then adds it to their DMARC record to protect >>> their domain. Now, when a receiver gets the upgraded message they see it is >>> a DMARC fail and can reject the message. This protects the `business.com` >>> domain from impersonation in a way that is not possible today without ` >>> business.com` either removing SPF or leaving their shared provider (the >>> only ways to "fix their SPF record"), both a much larger change. Does that >>> make more sense as a legitimate use case? >>> _______________________________________________ >>> 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 >> > _______________________________________________ > 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
