Re: [dmarc-ietf] PSD flag vs Version bump

[Alessandro Vesely <[e-mail]>]

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
--