-----Original Message-----
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org
[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)org] On Behalf Of Charles
Lindsey
Sent: Friday, October 15, 2010 6:52 AM
To: DKIM
Subject: Re: [ietf-dkim] layer violations, was detecting header mutations
after signing
That's why all of this hand wringing is silly.
We are not hand wringing. We are pointing out a protocol that, when
applied in the current (and likely future) Real World, fails to deliver
what it was intended to deliver.
This to me says you still believe DKIM's ultimate payload is something other
than a validated identifier, in this case a domain name. We're thus not on the
same page.
If instead we do agree that that's its sole intended purpose (and consensus on
the errata RFC was achieved, thus confirming this), then you also have to agree
that DKIM already does that. The MUAs simply fail to make use of it, and
that's the real problem.
DKIM does not purport to guarantee delivery of something that an MUA is
incapable of misrepresenting. The proposed changes don't improve this.
And since we're all insisting MUA developer and user inertia is here to stay,
then even all the fixes we're talking about aren't going to make the
enforcement of header field counts visible to end users; the sum and substance
of the impact will be that the Authentication-Results header field (or other
annotation) will change from "fail" to "pass", but this is rarely rendered to
end users, and so the problem remains.
RFC5451 says an Authentication-Results field shouldn't include in its
authentication summary any data that wasn't authenticated. Blocking
presentation of unauthenticated data, or highlighting it as dubious, or
outright obstruction of its delivery, are the right ways to deal with this.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html