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
