On Wed, Oct 25, 2023 at 8:56 AM Scott Kitterman <skl...@kitterman.com> wrote:
> > > On October 25, 2023 11:56:25 AM UTC, Alessandro Vesely <ves...@tana.it> > wrote: > >On Wed 25/Oct/2023 13:12:32 +0200 Barry Leiba wrote: > >>>> * Is there consensus on moving ahead with the idea of a way to > indicate which authentication method(s) the Domain Owner wants Receivers to > use? If so, it doesn't seem to be in the document yet. > >>> > >>> My recall is that we want to limit DMARC evaluation to DKIM only, for > the edge cases of domains with over-wide SPF policies, since they proved to > be vulnerable to false DMARC pass. The WG discussed the possibility to > also require both methods to limit replay, and concluded that the idea was > a foot gun. Hence the WG agreed on the comma syntax. > >> > >> My reading of the discussion is: > >> > >> 1. We did not have rough consensus to eliminate the use of SPF in DMARC. > > > > > >Yes. > > > > > >> 2. We did not have rough consensus to complicate DMARC by having the > publishing domain specify authentication methods. > > > > > >One thread started here: > >https://mailarchive.ietf.org/arch/msg/dmarc/PDktxOYkB28k6ukLDgDqlp6NEGw/ > > > >It ends up with Wei recapitulating the thread and summarizing the changes > to the draft. No objections. I expected those changes to be carried out. > > > > > >> Ale, you're saying that my reading on (2) is wrong, yes? Can you > provide support for that? > > > > > >I had only seen Scott's reading, which surprised me. After you and > Michael hold that no agreement was reached, I begin to doubt of my reading > myself. > > > >In particular, since there is a paper[*] showing how a "spoofed email > >purporting to be b...@state.gov is delivered to a Gmail user’s inbox > with no warning indicators", Wei's argument seemed to be fully reasonable. > > > >What outstanding objections were there? > > The purported use case is "my SPF is so awful you can't trust it and at > the same time, so critical I still have to publish the record". I don't > think that's a real thing. > > If your SPF is unreliable, fix it or delete it. Not a DMARC problem. > +1 We need to stop confusing operational/implementation issues on the part of some with issues that reflect poor logic in a standard. Michael Hammer
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
