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