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

Reply via email to