[ietf-dkim] double header reality check

[Scott Kitterman]

"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.

Confusedly yours,

Scott K