On 2/3/2024 12:11 PM, John Levine wrote:
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.
It has to treat CRLF differently. What is the reason it has to treat
isolated occurrences of one or the other differently, beyond what I
noted in my previous message? What is the DKIM-specific reason?
I keep asking and you keep not responding.
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.
"It already does" is not a reason it needs to.
As for what I believe, please stop distorting what I've said.
d/
ps. You seem to have missed that, in fact, bare CR and bare LF are legal
in messages.
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social
_______________________________________________
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim
