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.
Cheers,
Steve
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html