On 10/20/10 3:19 PM, Murray S. Kucherawy wrote:
[]
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).
a) please.
In this case, "low quality" really means "misleading results". Why are
you reticent in adding obvious checks, that I am sure your code will
include. Not making this a MUST return PERMFAIL for multiple From
header fields otherwise means DKIM results can never be trusted. The
results would not offer interchangeable implementations, since it is
unreasonable to expect consumers of DKIM results will always make the
relevant checks that might have been missed, or that SMTP will now
suddenly alter its level of compliance checking.
This is really about checks that will consume only a few CPU cycles,
since the information is already touched by the verification process.
What is a few picoseconds between friends? :^)
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html