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

["Murray S. Kucherawy" <[e-mail]>]

On Mon, Feb 5, 2024 at 8:50 AM Dave Crocker <[e-mail]> wrote:

> 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.
>

Yeah, as I said, I wish I could remember.  It's a bit of a contradiction.
My best guess is that something was injecting messages without a Date field
knowing the MTA (sendmail, in this case) would add one.  But this had the
effect of causing the filter to oversign that field, so the MTA adding one
immediately invalidated the signature.  Adding this check avoided that
problem.


> 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.
>

Yes indeed, though in my case I was compensating for an implementation
choice in the MTA to which the filter provides a service, and I don't have
direct control over the MTA's 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.
>
Yes, I agree that the specification should follow what I call the "pure"
angle, but also be abstract enough not to constrain implementation to
enable reality.

> (*) 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.
>

Interesting.  Is that online anywhere?

-MSK