It appears that Dave Crocker <dcroc...@bbiw.net> said: >> Any DKIM signer or verifier already has a state machine looking for CR >> and LF to do header or body canonicalization. When the state machine >> runs into a bare CR or LF, it has to do something. The only options >> are to produce a wrong result, since there is no correct result, or no >> result. (As I said in a recent note to Murray, which wrong result is >> likely to vary depending on local file details.) You seem to be >> saying that as a matter of principle it should produce a wrong >> result. I'd rather not. > >The state machine has to process /every/ character. You are focusing on >two that have special DKIM meaning, when occurring together, but that's >too narrow. In practical terms, the state engine is evaluating every >character.
Sorry, I thought it would be obvious that it already has to treat CR and LF differently, and it already has special cases for what follows CR and (on systems that don't turn CRLF to LF on the way in) what precedes LF. >In focusing down so narrowly, you've missed the basic point I made: >DKIM has no inherent reason to care about these characters' occurring in >isolation. ... Sigh. Except that it already does. You've made it clear that you believe there is a principled reason to produce invalid signatures from invalid input. Whatever. R's, John _______________________________________________ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
