On Oct 20, 2010, at 6:08 PM, Scott Kitterman wrote:
"Michael Thomas" <mike(_at_)mtcc(_dot_)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