In that light, taking an additional step wrt duplicate headers (or
malformed 2822 in general) is still in the same layer as the verifier.
My objection isn't so much layering within the software, because I know that
gets mushy real quick, but layering among the protocol specifications. For
example, we wouldn't include in an SMTP specification some text about dealing
with fuzzy TCP implementations, and what people are talking about here makes
just as much sense to me.
The problem is that I don't think we are really just talking about
getting a protocol right from a bits perspective.
If DKIM has any value it's that it ultimately affects the user mail
experience for the better. Consequently, to remain silent on matters
that we know will adversely affect that experience seems
contradictory. Similarly to not offer guidance to implementors on the
sorts of things they can do to maximize the value of DKIM seems
similarly to miss the point.
Furthermore, DKIM specifically came into existence to deal with an
adversarial environment whereas 821/822 and the like have very
specific "just get the bits right" goals.
So guiding verifiers to assume the worst seems consistent with our
intent or at least our genesis.
Mark.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html