On Wed 02/Apr/2025 10:45:43 +0200 Steve Atkins wrote:
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. [...]
Since you mentioned it, let me note that OpenDKIM is composed of a library
part, that does the actual crypto, and a main program, that handles the MTA
interface. In order to create OpenARC, the library part was forked and the
names of the variables adjusted as appropriate, then adding new functions as
needed.
Following the same path, an OpenDKIM2 can make a copy of either one of the
previous packages and modify it as needed. I dislike this approach, as a bug
in, say, the key retrieval function would have to be fixed both in
arc_get_key() and in dkim_get_key().
[...]
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)
What cruft? l=? I figure libopendkim has less than 100 lines of code about
dkim_partial, including comments, out of more than 20,000.
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.
I don't think the design space is much smaller, given that the bulk of RFC 6376
is going to be referenced. My impression is that we're extending DKIM, not
shortening it.
(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.)
IME, failures to validate are due to MTA rewriting.
DKIM is not going to die any time soon, so any bugs in it should be found and
fixed anyway. I'd certainly prefer to fix them in only one place.
Best
Ale
--
_______________________________________________
Ietf-dkim mailing list -- ietf-dkim@ietf.org
To unsubscribe send an email to ietf-dkim-le...@ietf.org
