On Oct 20, 2010, at 6:08 PM, Scott Kitterman wrote: > > > "Michael Thomas" <m...@mtcc.com> wrote: > >> On 10/20/2010 04:36 PM, Steve Atkins wrote: >>> >>> 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. >> >> I think that Steve threads this just about right. No need to cast aspersions, >> or kick them off the "compliant" island. Just lay out the security >> consideration >> and let people deal with this however makes sense. I'm still puzzled how this >> tempest entered this tea pot. >> > Um. That's not how I read what he wrote. He specifically said no to security > considerations
I don't think I did. The "informative note" would probably be something informative, rather than prescriptive, in the security considerations section. What I wouldn't favour would be a MUST or a SHOULD or anything morally equivalent to either, as it's outside the scope of a DKIM specification to do that. > and I understand that's what you're in favor of. Cheers, Steve _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
