> -----Original Message----- > From: John R. Levine [mailto:[email protected]] > Sent: Thursday, October 21, 2010 9:07 AM > To: Murray S. Kucherawy > Cc: [email protected] > 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
