+1
Bill Oxley
Messaging Engineer
Cox Communications
404-847-6397
-----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