[ietf-dkim] double header reality check
ietf-dkim at kitterman.com
Wed Oct 20 18:08:58 PDT 2010
"Michael Thomas" <mike at 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 and I understand that's what you're in favor of.
More information about the ietf-dkim