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