I'm still cringing at the layering violation of "fixing" in DKIM the
fact that many RFC5322 implementations, MTAs, MSAs and MUAs alike,
don't bother to enforce normative portions of that specification.
The standard advice has always been to accept malformed mail and render
it as best you can, on the theory that it was probably from a legit but
buggy sender. Other than this DKIM issue, that's still good advice.
Here's another way to look at it: if we think that adding extra headers is
a significant threat, someone's going to have to check for them. History
suggests that in the absence of DKIM, it's not worth doing since nobody
does it. That also suggests that all the places other than a DKIM
verifier will continue not to do it, since it's still of no great benefit.
So if we don't do it in the verifier, it's not going to happen.
"Our software works, but you have to make changes of no direct benefit to
yourself to plug a hole we could have plugged" has rarely been a winning
argument in the past.
R's,
John
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html