> 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
