On 2/3/2024 10:32 AM, John R Levine wrote:
On Sat, 3 Feb 2024, Dave Crocker wrote:
Having a DKIM module check for one aspect of RFC5322 conformance
raises a need to make it a full RFC5322 compliance engine.
That's easy: no, it doesn't.
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.
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. DKIM is not a message validation engine. It is a
DKIM-specific engine. One more time: DKIM has no requirement of its
own that cares about a bare CR or bare LF.
If you think otherwise, please explain, in terms of DKIM syntax and
semantics, independent of a general message format specification.
And the point I made was not that it was difficult to add code to raise
an exception when one of them occurs on its own, but that DKIM is the
wrong place to put the exception. And that makes it likely there will be
a maintenance problem down the line.
Imagine, if you will, that the email format standard changes to make CR
and LF acceptable to occur, each on their own. This is not all the
impossible, given that they were entirely legal in RFC 733 and RFC822.
In fact, upon reviewing the different versions, I see that they are
/still /legal in RFC 2822 and RFC 5322 and RFC5322bis parsing, with some
text implying why there was a change from being fully legal.
/<rant> While I understand the explanation, I don't agree with the
change, since I think it deals with local misbehaviors by changing
global standards behaviors. More likely, the better way to think of it
is that the global details have not been specified precisely enough. So
I think the fix is to define the semantics of each character globally
and require local engines to match it, as they already have to do for
newline. </rant>/
Hmmm... So it seems that the claim that they are illegal is not correct!
But let's continue the hypothetical that they are illegal. If/when they
become legal, there has to be memory that DKIM treats them as illegal.
DKIM is not a general message parsing engine, so it entirely possible
(likely) that the maintainer of DKIM code will not know to make the change.
Since DKIM does not need to care about bare occurrences of these
characters, things are kept simpler and frankly easier to maintain, by
having bare occurrences pass through as other characters do. The fact
that the appearance of a bare CR will raise a flag (or change a state)
in case the next character is an LF is a distraction to the current
issue. It does not require failing the DKIM-specific parse, because in
terms of what /DKIM /itself needs to care about, a bare CR and a bare LF
are just characters like any other.
d/
--
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
