On Oct 20, 2010, at 3:19 PM, Murray S. Kucherawy wrote: >> >>> Validating mail syntax belongs in the specification for the mail >>> components and DKIM work belongs in the DKIM components. >> >> That's why, layer violation or no, I think it's important to distinguish >> between format errors that are likely to lead to misleading rendering in >> existing MUAs, and the much larger class that may produce nonsense but >> won't produce lies. > > I think we're close to converging here. > > I totally agree that that's an important distinction to make, document, > highlight and shout from the rooftops. But... Does it *have* to use RFC2119 > normative language? > > Here's maybe a better way to frame the question: Should we empower ourselves > to label a DKIM implementation that doesn't do format enforcement as (a) > non-compliant, or (b) low-security/low-quality? > > I'm pushing for (b), while someone who insists the text be normative is > pushing for (a).
I'm pushing for neither. It's not the DKIM verifiers responsibility to enforce that. I do think that an informative note observing "Here are a couple of issues that might theoretically be exacerbated by a DKIM-using world; you might consider checking for these problems somewhere in your mail handling path, if you aren't already" would be reasonable. "Somewhere in your mail handling path" might be in the same binary as the DKIM validator, or it may not - and implying that an implementation that chooses to handle two entirely separate validation issues in two separate modules is "non-compliant" or "low-security" or "low-quality" doesn't seem helpful. Cheers, Steve _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
