On Sun 11/Jun/2023 00:32:01 +0200 Richard Clayton wrote:
Personally (and I am not writing on behalf of $DAYJOB$) I think that
signal "I know things have changed and am setting things up accordingly"
is most clearly sent by bumping the version number, rather than relying
on other more subtle syntax changes.
Among changes, besides the tree walk, we have ed25519 and t=. Compatibility
seems to be much more at stake with the latter ones than with the former. In
fact, if you sign with (only) ed25519, many receivers won't verify. If you use
pct=5, like some do, you may be off for some harsh surprises. In contrast, if
your record is found by walking the tree rather than looking up the PSL, most
likely you won't even notice.
We don't need psd=u's, except if we're drawing statistics.
New tags can be added also after DMARCbis is out. There is a registry already:
https://www.iana.org/assignments/dmarc-parameters/dmarc-parameters.xhtml#tag
Not all receivers recognize every tag. There was a project to syntactically
denote tags that cannot be ignored, and it was abandoned (also) because it
required a version bump.
Conserving the installed base is important.
I foresee almost no enthusiasm for running two systems in parallel in
perpetuity. Running the simpler __system__ is clearly better all round
but I do think that the fact that there are changes should be signalled
very clearly rather than deduced ... it will make the messaging to the
masses rather than the cognoscenti so much simpler.
What if MIME-Version changed on every new MIME type?
We'd be running n systems in parallel, with n -> ∞. Introducing a new system,
however simpler, would divide the users community, rather than unite them.
https://xkcd.com/927/
Best
Ale
--
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
