-----Original Message-----
From: John R. Levine [mailto:johnl(_at_)iecc(_dot_)com]
Sent: Thursday, October 21, 2010 9:07 AM
To: Murray S. Kucherawy
Cc: ietf-dkim(_at_)mipassoc(_dot_)org
Subject: More on layer violations
Having pondered the layer thing some more, it occurs to me that we have
several decades of practice with software that validates the format of
mail messages to a greater or lesser extent, with the emphasis on lesser.
Different software depends on different bits of the message to be correct,
which means that some leakage of the message validation into different
applications is unavoidable unless you're willing to lose mail that has
flaws that don't matter to the applications that it passes through.
In procmail, for example, doubled subjects only matter if you have a rule
that does something depending on the subject line. In MUAs, based on the
random way existing MUAs handle them, they don't matter at all.
All true. But those are implementations, not specifications.
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