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

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

On Sat, Feb 3, 2024 at 5:40 AM Dave Crocker <[e-mail]> wrote:

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

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:

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.

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.[*]

It also optionally does LF to CRLF translation.  I'm fairly certain this is
to accommodate local/human SMTP injections since humans can't be expected
to type CRLFs when entering manual tests from a shell.  Again, though, this
only alters what's fed to the hash, as it expects the MTA will do this
conversion before the message is relayed en route to its destination; not
doing so dooms the signature to failure.

I think most of this is because the original milter interface, on which
this work was based, is an SMTP input filter.  Output filtering wasn't
originally available, meaning the filter saw the raw form of the input
rather than a "treated" form, and had to anticipate what the recipient
would see.

Maybe this illustrates the difference between pure software engineering and
applied software engineering?

-MSK

[*] The success of this feature is what makes me think a "list transforms"
extension to DKIM might also succeed.