There is a close parallel here with HTML and XML HTML requires processors to be lax which causes real problems because people rely on laxness
XML requires processors to be strict which causes real problems because the systems end up brittle. I don't see a problem with heuristics. The problem is caused by reliance on heuristics. I don't think that is an issue here. The job of doing the heuristics is sufficiently a pain to ensure that there are not going to be a lot to rely on. SHOULD NOT is sufficient to ensure that coverage is not enough to create reliance. > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Michael Thomas > Sent: Friday, January 05, 2007 12:36 PM > To: [EMAIL PROTECTED] > Cc: [email protected] > Subject: Re: [ietf-dkim] mutant message validation, was Base > issue: multiplelinked signatures > > Wietse Venema wrote: > > John Levine: > > > >>>>> From my perspective having a message have a valid > signature with > >>>>> one > >>>>> > >>>> implementation and having a broken signature with another is an > >>>> incompatibility. I don't think that's speculation. ... > >>>> > >>> No, it merely reflects a difference of opinion by the sites > >>> concerned as to what changes it will tolerate in a > message before it > >>> recommends to its clients that the message should be > dropped. It is > >>> not the job of our standard to dictate local policy > issues at that level of detail. > >>> > >> I agree that we are not dictating local policy. But I > really think > >> that it's our job to dictate the definition of what the signature > >> validation algorithm is. As I've said before, everyone > remains free > >> to do whatever they want with messages whether or not the > signature > >> verifies, including applying various heuristics to develop > opinions about unsigned messages. > >> > > > > Perhaps some people are confusing verification and presentation. > > > > Verification: it is critical that all DKIM verifiers agree > on what is > > a valid DKIM signature, without falling back on heuristics, such as > > heuristics to repair messages. > > > > Presentation: after the valid/invalid decision is > irevocably made, it > > is up to application/policy to decide how/if things will be > presented > > to users. Heuristics of various sorts can be useful in > this domain, > > such as message repair, known signer associations, etc., but those > > heuristics must not determine the validity of the DKIM signature. > > > I really don't understand all of this hand wringing about > True Verification vs. Mutant Verification Intent on Taking > Over Earth. The protocol document needs to be precise about > what it takes for a properly written verifier to verify a > properly signed message. That's it. Trying to make normative > any or all of the ways _not_ to verify a signature is not > only a waste of time, it's a hopeless task. Having > informative text to guide implementors with potentials > gotchas, corner cases, and other possible misinterpretations > is fine to a point, but making them _normative_ makes no > sense whatsoever. > > > Mike > _______________________________________________ > NOTE WELL: This list operates according to > http://mipassoc.org/dkim/ietf-list-rules.html > _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
