On Sat, Feb 3, 2024 at 5:40 AM Dave Crocker <d...@dcrocker.net> 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.
_______________________________________________ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
