> On Oct 28, 2023, at 5:01 AM, Alessandro Vesely <ves...@tana.it> wrote: > > On Fri 27/Oct/2023 20:06:46 +0200 Scott Kitterman wrote: >>> On October 27, 2023 5:54:03 PM UTC, Alessandro Vesely <ves...@tana.it> >>> wrote: >>> On Fri 27/Oct/2023 12:34:11 +0200 John Levine wrote: >>>> If there isn't a consensus to do a DKIM-only feature, which seems to be >>>> the case, I agree, wrap up the few minor editorial issues and we're done. >>> >>> If we add the feature, we should in any case exemplify how to fix SPF, >>> saying that doing so is safer, at least until all DMARC software has >>> acquired the new feature. As the addition would be understood as a >>> response to the known vulnerability, it will likely be spread. >>> >>> As many of us consider it cleaner to have DMARC based on DKIM only, having >>> that possibility as an option is a first step in that direction anyway. >>> The thesis that DKIM is enough has been opposed but the only cases where >>> SPF saves the day seem to be software bugs. The DKIM-only feature would >>> allow to probe that thesis, which fixing SPF records would not. >> >> What do we know now that we didn't know the last time we decided not to go >> DKIM only? I'd argue there's nothing and endless relitigation of issues >> like this is making it impossible to actually accomplish what we're >> chartered to accomplish. > > > You're the only one strongly opposing the idea, AFAICS, and I still don't > know why. > > >> Let's either focus and finish or give up and close the group. > > > Even if we don't add the feature, we should address the vulnerability. > Currently there is only a bullet in Section 4.8, Organizational Domain > Discovery, saying: > > * The domain found in the RFC5321.MailFrom header if there is an SPF > pass result for the message being evaluated. > > We need to add a subsection in Security Consideration, discussing an example > of an include mechanism with a neutral qualifier and its effect on DMARC > outcome; that is, how that avoids spurious authentications. > > The other snippet where SPF qualifiers are discussed is Section 8.1, Issues > Specific to SPF. We could add a reference to the added subsection there. > If explicit language gets us a good portion of the way there. That is forward progress for those who support this. Alexandra there must be others not willing to go that direction and digging in wil just mean this same conversation 6 months ago. To keep it neutral the hums should prevail now and those who lost this one, remember the battle may be winding down but you have time to provide tangible evidence this was a brain dead decision. I’m guess WG members are smart and experience quite a bit of neurogenesis (I.e., don’t hold to an idea for ego certitude). Even if those who don’t hum hate it, take solace that time will show you right if you are right and I doubt anyone humming will hum that dissonant song of wrong again.
If the no hummers are right I hope they humbly re litigate this and change a bad policy. Let’s test drive this baby and see if it breaks down out in the boonies. > > > > > _______________________________________________ > 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
