> > 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
