> On 2 Apr 2025, at 00:26, Michael Thomas <m...@mtcc.com> wrote:
>
>
> 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:
Smaller and simpler means cheaper maintenance and fewer bugs. The smaller the
design space, the easier it will be to test thoroughly.
(There were still known bugs in widely deployed DKIM libraries that caused them
to fail to interoperate a few years ago; I’m sure there still are, I’ve just
stopped paying attention to the unexplained failures to validate.)
Cheers,
Steve
>
> [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
_______________________________________________
Ietf-dkim mailing list -- ietf-dkim@ietf.org
To unsubscribe send an email to ietf-dkim-le...@ietf.org
