Re: [Ietf-dkim] Question about lone CR / LF

[Dave Crocker <[e-mail]>]

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:@[e-mail]