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: ietf-dkim-bounces(_at_)mipassoc(_dot_)org
[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)org] On Behalf Of Michael Thomas
Sent: Friday, January 05, 2007 12:36 PM
To: ietf-dkim(_at_)porcupine(_dot_)org
Cc: ietf-dkim(_at_)mipassoc(_dot_)org
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