-1.
This is not a LAYER violation. DKIM is a protocol for RFC
822/2822/5322 data to:
a) verify a message signature, and/or
b) create a message signature.
In order to do either requires INPUT that MUST be valid for the
protocol to be fundamentally correct with its OUTPUT.
Therefore it MUST make sure its input is 100% valid.
This is not different than any function generator that checks its
boundary conditions. A robust function generator MUST check its input
otherwise you have faults, chaos, aborts, GIGO - Garbage In, Garbage Out.
DKIM is fundamentally a security protocol and it will be insane to
believe that it should allow GIGO to occur due to not checking it
input validity.
A Layer Violation is when you are asking for data bits that in
821/2821/5321 (or another our feed) and/or also producing BITS that
other layers like a MUA might use.
We are not doing the former but would be if we bind bits like a
Return-Path. We are differently doing the latter with the creating of
more bits for other LAYERS to use.
DKIM validating its INPUT is not a layer violation and in practice, it
will be extremely bad product engineering. In fact, I would go as far
to make it an ethical engineering responsibility for ALL DKIM
components to make sure its not a GIGO engine.
Now, if that doesn't jive with the "IETF DOCS" well, thats an entirely
different issue. Most implementators are not going to GAS (Give a
S$$$) what that docs says or doesn't say if it not providing what is
fundamentally necessary.
The DKIM component MUST check its input and at least one independent
API has done so (on the verify side for 5322.From only). It could not
pass the buck to 822/2822/5322 message generators or verifiers.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
Murray S. Kucherawy wrote:
You can add OpenDKIM to that list. Like I said, it already does do the
validation, but that's because RFC5322 says so, not because RFC4871 says so.
And I think that's the way it should stay.
Take a tour through the eleven parts of Section 7 of RFC5451, and then
Appendices A and C. They provide all kinds of warnings about misinterpreting
the data provided, which amounts to pretty firm implementation advice, and
identifies ways you can shoot yourself in the foot. But none of those
sections are normative. (Actually there are two SHOULDs in 7.4, but in
retrospect they shouldn't really be there.)
That's what I'm advocating here: The normative stuff defines the core
mechanics of the protocol itself, and the informative stuff explains why it's
done that way, detailed implementation advice including stuff about other
layers, and how one should (and shouldn't) interpret the output.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html