On 2/3/2024 1:13 PM, Murray S. Kucherawy wrote:
I generally agree with the idea that there's a layering problem here,
i.e., that a DKIM filter should be able to safely presume that its
input will comply with RFC5322 and not alter the message at all other
than adding the signature. But on review, it seems like I've tiptoed
over that line from time to time in support of robustness in some form
or another. For instance:
The 'problem' is the difference between the abstract networking
architecture, which can -- and for DKIM does -- have clean interfaces,
versus software implementation that might have all sorts of local
optimizations for efficiency, robustness, or the like.(*)
Keeping very clear about this difference is how we can get a simple,
correct standards specification that permit the widest reasonable range
of implementation choices.
The only danger in local optimizations is that they might embed requires
on the world outside of DKIM that won't be remembered if/when that
outside world changes. (I'm sure /you/ wouldn't be guilty of that, of
course, but most of us aren't from Canada.)
OpenDKIM will not sign a message that fails basic RFC5322 header
checks (e.g., "From" or "Date" is missing), but will place an
Authentication-Results field indicating the message is malformed. At
some point, though, someone talked me into making it possible to
bounce such a message in the filter. I wish I could remember the full
context.
So you are enforcing an RFC5322 requirement for From and Date to be
present, although the DKIM spec only requires signing From.
Why are you doing that?
Imagine RFC5322++ removes the requirement for Date. (In fact I had not
remembered Date is required, going all the way back to RFC733. sigh.)
That requires remembering and changing DKIM code.
I understand the desire to do this extra checking, but not the
justification for giving in to it, inside DKIM.
It also allows for specification of things that are likely to be
rewritten downstream (e.g., address canonicalization), which it can
then simulate when computing its hashes, in order to make validation
of the signature at the verifier more likely to succeed.[*]
"likely to be rewritten downstream" is clearly part of local
implementation design choices.
While possibly quite reasonable to make for the implementation, they
have nothing to do with the standards specification, other than to
encourage writing standards that neither require nor inhibit such choices.
d/
(*) Lon ago, Knuth visited UCLA when I was there, and 'structured
programming' was a hot topic. He did a presentation to test a
perspective that he later wrote up. He observed that fully structured
programs, without gotos, could sometimes make code /worse/. He shows
some code without any gotos that was correct but extremely difficult to
read and understand. Then he showed a version, with two loops -- one
after the other -- and inside each was a goto into the other. OMG. But
this code was clear, concise and easy to understand.
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social
_______________________________________________
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim
