"Michael Thomas" <[email protected]> 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 and I understand that's what you're in favor of. Confusedly yours, Scott K _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
