On 4/1/25 3:19 PM, Richard Clayton wrote:
In message <d099eead-11aa-4bfd-8d55-1ce144c01...@mtcc.com>, Michael
Thomas <m...@mtcc.com> writes
> Two different code paths, two different places for screw ups and
> maintenance. I'm with Murray that there is a lot of appeal to backward
> compatibility.
why would you want to maintain a codebase that handled both DKIM1 and
DKIM2 ...
Because it's easier? Because the base functionality has already been
vetted and deployed? I don't know whether openDKIM is available in the
various repos, but if it is an update to the milter/library or MTA
itself, it can be as easy as just updating the package where deployments
pick up the change the usual way. Then you're just having a discussion
about the new features/policy aspect rather than that *and* whether it
is safe to deploy, *and* whether adding another signature is going
affect performance, etc, etc.
If the proposed new protocol is so gratuitously different that you have
to write a new implementation, that is very distinctly negative and
makes it highly unlikely you'll get buy in at all. DKIM as it turns out
was at the right place at the right time and got lucky, imo. Something
that solves abuse vetting problems of an ESP's clients is not going to
have unaffected deployments champing at the bit to deploy if it's brand
new because they little if no incentive. A software update to their
existing infrastructure is a much easier sell, where they can upgrade
and then decide if they want to take advantage of new features or not.
you would have more than double the number of test cases to
maintain (DKIM1 has a fair amount of cruft that no-one actually uses, so
a DKIM2 library is going to be smaller and simpler)
Who cares? These micro-optimizations are pointless. It solves a problem
that nobody is asking to be solved. I'm just trying to imagine the
conversation with a CIO:
[DKIM2] "The DKIM2 library is going to be smaller and is going to be
more CPU efficient! Isn't that great?"
[CIO] "How much smaller?"
[DKIM2] "Maybe 1k byte!"
[CIO] "How much more efficient?"
{DKIM2] "230 nanoseconds!"
[CIO] ::pushes the button to the moon door::
> This is hardly a controversial software development practice.
nor is forking ... it's not as if DKIM1 libraries are under constant
revision so that you would have to apply fixes in two places
Forking? Something that's backward compatible doesn't need to be forked.
That's the entire point of making it backward compatible is so you
*don't* need to fork or rewrite.
Mike
_______________________________________________
Ietf-dkim mailing list -- ietf-dkim@ietf.org
To unsubscribe send an email to ietf-dkim-le...@ietf.org
