To the extent we might need it so far, I think the psd= tag is that flag. Scott K
On June 10, 2023 7:34:59 PM UTC, Tim Wicinski <tjw.i...@gmail.com> wrote: >I'd rather add an option to flag some behavior rather than do a version >bump. > >Have to agree with Scott that version bumps take forever. >(I had a network engineer recently tell me that DNS packets *MUST* be no >larger than 512 bytes - and EDNS0 was 1999?) > >tim > >On Sat, Jun 10, 2023 at 3:03 PM Scott Kitterman <skl...@kitterman.com> >wrote: > >> >> >> On June 8, 2023 12:58:51 PM UTC, Tobias Herkula <tobias.herkula= >> 401und1...@dmarc.ietf.org> wrote: >> ... >> > >> >However, such a fundamental shift in the protocol's architecture warrants >> a clear signifier. I suggest we upgrade our DMARC version string from the >> current state to 'DMARC2.' This upgrade would not only denote the change of >> SPF removal, but also the switch from the Public Suffix List (PSL) to the >> Tree-Walk algorithm. >> > >> >By moving towards DMARC2, we not only update our standard to better >> reflect our present requirements, but we also make a clear commitment to >> the ongoing evolution and improvement of the protocol. >> >> >> There's been a fair amount of discussion of the drop SPF part of this >> proposal, but I think less about the question of version bumps. I'm going >> back to the top of the thread to focus on that. >> >> I don't think there's much precedent for version bumps being successful in >> any reasonable time frame. How long did it take to transition from SMTP to >> ESMTP? Is it done yet? Absent IPv4 address exhaustion, how many more >> decades would it have taken for IPv6 deployment to take off? SSL/TLS is >> the best example I can think of, but even that, where there are very strong >> security and privacy incentives, has been too slow and very painful. We >> have nothing like that level incentive for people to support an >> incompatible break between non-IETF DMARC and IETF DMARC. >> >> Technically, it's a new protocol. There's no technical difference between >> saying records now have to start with v=DMARC2 and they have to start with >> v=NOTDMARC. It's a decision to abandon all existing deployments and start >> over. >> >> What's the incentive that any existing DMARC users (senders or receivers) >> would have to invest additional resources in another email authentication >> protocol? My expectation is that if the IETF decides to bump the version, >> very little deployment of the IETF variant. "The IETF says this one is >> better" doesn't move budgets in any meaningful way. >> >> My suggestion is that if we determine that a change requires a version >> bump, out response should be to not make that change instead. >> >> For clarity, I don't think the tree walk should drive a version bump (and >> we already went over that, let's resist the temptation to do it again), but >> if it did, then I would rather stay with the PSL. >> >> Please, no version bumps. >> >> Scott K >> >> _______________________________________________ >> 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
