> I don't think that's a fair characterization. It is simply wrong to try to > deal this problem in DKIM. For example, a bug in the TCP stack that causes > malformed data to arrive in an application which in turn causes something > visible and unexpected, possibly even something dangerous, to happen in that > application is still a bug in the TCP stack and saying so puts the > responsibility for resolving the problem where it belongs.
Yeahbut. Isn't that conflating detection with fixing? Lots of protocols have end-to-end or layer-to-layer verification to detect intervening bugs. You also well know that treating all external input with the greatest suspicion *almost* goes without saying in any programming endeavour, but particularly so in this one. I agree that a full 2822 parser is over the top and something that is unlikely to exist near verification code, but we do need to instruct verifiers to be suspicious and untrusting. What's the middle ground? Serendipitously, my early implementation refused to verify an email that had a From: prior to the signature header. The general problem is that applying authentication results to the whole payload is wrong. I don't argue this, but one could consider removing or denaturing all payload outside of the signature... Mark. _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
