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

[Steffen Nurpmeso <[e-mail]>]

John R Levine wrote in
 <[e-mail]>:
 |> 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)