John R Levine wrote in <[email protected]>: |> 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.
I cannot "correct" data as it comes in, unless i replace the entire message with the corrected version, that much is plain. This is about a cryptographically verifiable signature, so whoever sits on the receiver end has to be able to reproduce it. The real-life situation is anyway a disaster, as body content as such is mostly transparent to SMTP implementations, and address fields can be messed up, and DKIM implementations make decisions based on those. Unfortunately the milter protocol sends headers as field/body pairs, and the milter has to parse the body itself. On that front i know no DKIM milter in use which is failure proof. |> 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. This is not true for postfix. Postfix prepares the message for SMTP, and sends that prepared message to the milter. I only ever see CRLF here. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) _______________________________________________ Ietf-dkim mailing list [email protected] https://www.ietf.org/mailman/listinfo/ietf-dkim
