Since SPF "Best Guess" is mentioned ... This was developed very, very early in the SPF project to help bootstrap the protocol when not very many domains published records. When the original SPF RFC, RFC 4408, was developed, it was considered for standardization and the judgment of the community was that it was not suitable for standardization.
Fundamentally, both SPF "Best Guess" and "Virtual DMARC" destroy the opt-in nature of SPF and DMARC and should be considered harmful. If an entity wants to apply this kind of test, it's a purely internal policy decision. No RFC needed. Authentication Results already provides for documenting policy results. No need for trying to shoehorn this into DMARC results. It's not a DMARC result. This is not only not opt-in, there's no opt-out mechanism. Please don't do this (same as last time this came up - yes, I did check the slides to see if anything has changed and it hasn't). Scott K On Monday, March 19, 2018 09:02:15 PM Yasutaka, Genki | Dkim | OPS wrote: > Hi Steven, > > Thank you for your comment. > > You can download from the following link. > > https://datatracker.ietf.org/meeting/agenda.html > > - Virtual DMARC: DMARC verification without record definitions > > I will send you directly just in case. > > Regards, > Genki > > --- > Genki YASUTAKA > > Rakuten, Inc. > Mail: [email protected] > > -----Original Message----- > From: dmarc [mailto:[email protected]] On Behalf Of Steven M Jones > Sent: Tuesday, March 20, 2018 4:15 AM > To: [email protected] > Subject: Re: [dmarc-ietf] [Request] Presentation in IETF101 > > I want to thank Yasutaka san for presenting the Virtual DMARC proposal. > I believe the situation he and his colleagues are addressing would benefit > from more attention. > > The meeting materials at IETF do not seem to include Yasutaka san's slides. > If I didn't just miss it, would it be possible to share that presentation? > > Aside from changes to the "dmarc=" allowed values in > Authentication-Results: - and I think this echos a point made during the > session - the underlying issue seems to be the use of DMARC-style alignment > checks in the absence of a DMARC policy record. > > That practice may be useful to the receiver's evaluation of SPF and DKIM > results. Perhaps that should be explored as a receiver/authenticator best > practice. It may be _very_ useful to capture these statistics to make it > clearer to domain-owners/senders that more current email traffic would pass > DMARC checks than they may presently realize. I would definitely like to > explore that further. > > But DMARC is based on cooperation between domain-owner/sender and > authenticator/receiver. And it depends on the explicit > opt-in/request-for-treatment from the domain-owner, signaled by a public > DNS record, and the reporting mechanisms so that the domain-owner/sender > can correct errors in implementation of authentication measures. > > Virtual DMARC seems to be discussing only what happens within the > authenticator/receiver, but perhaps I have missed this part. I look forward > to re-reading the proposal and slides with this in mind. > > --Steve. > > Steve Jones > DMARC.org, LinkedIn, crash.com, etc. > > _______________________________________________ > dmarc mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dmarc > > _______________________________________________ > dmarc mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dmarc _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
