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

[Dave Crocker <[e-mail]>]

On 2/1/2024 8:34 PM, John Levine wrote:
> I can see that you have strong opinions about what a DKIM verifier
> should do with those non-5322 blobs, but I don't see what the basis
> for that is, and for that matter, I don't really understand what you
> expect code to do with them.  Why is "stop and report failure" any
> less valid than anything else?


I thought I supplied the key point in my response to Jon:

> A 5322 processor gets to decide what is a valid message.  That's not 
> DKIM's job.  And DKIM has no inherent reason to care about CR or LF on 
> their own, as distinct from any other character on its own.


You moved things to the concept of layering, which wasn't quite the 
concern I was raising, but is probably reasonable as an encompassing 
construct.

You claimed DKIM has never conformed to layering and I asked you to 
explain.  I included an explanation for why there is no obvious basis 
for your assessment, especially since the example you gave appears to 
have nothing to do with layering, given that what you cited is something 
entirely internal to DKIM.

I didn't see a clarification from you, about this.


But since these foundational points aren't sufficient for you, I'll 
elaborate, although having to discuss the benefits of design and coding 
discipline is a bit surprising.  It made sense 40 or 50 years ago, when 
software engineering was an emerging discipline, but I'd thought the 
industry was a bit more mature than that by now.

Having a DKIM module check for one aspect of RFC5322 conformance raises 
a need to make it a full RFC5322 compliance engine.

If it doesn't, then the  attention to compliance is a random walk 
through whatever concerns are fashionable at the moment.  That is, is 
sprinkles stray bits of compliance code in a place that won't be -- and 
shouldn't be -- expected to have it.

As maintenance nightmares go, over the long term, this is a pretty 
classic example.  As things related to RFC5322 change over time, and 
personnel changes remove specialized knowledge, it will not be obvious 
to check whether this module needs changing.

When a DKIM module is invoked, it should be invoked with necessary input 
validation checking already done.  If it hasn't been, then there are 
larger system problems that stray bits of code in the DKIM module won't fix.

d/

ps. Yes, I do have strong feelings about thoughtful design discipline.  
It usually produces cleaner, simpler, clearer results.

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@[e-mail]