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. ...
It occurs to me that Dave and I have different views of how software is put together. His sounds like the waterfall model that was popular when he and I were undergraduates. You design the whole thing, you decide what modules do what, then you code the modules. So if module A is supposed to do something, there's no reason for module B to worry about it because A should already have handled it.
My view is more pragmatic. People assemble programs from pieces and the pieces have bugs. So to the extent practical, you defend against things like bad input. It happens that bare CR and LF are really easy to check for in DKIM since as I noted before there's already a state machine that is looking at the current character and knows if the previous character was a CR. So it might as well recognize and reject that particular bit of bad input, particularly since whatever result it would otherwise produce isn't likely to be useful.
Maybe this illustrates the difference between pure software engineering and applied software engineering?
Yup. R's, John PS:
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. ...
Unix MTAs strip out the CR in CRLF, often on the way in, so by the time opendkim sees the message, the line endings are just LF.
_______________________________________________ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
