[ietf-dkim] layer violations, was detecting header mutations after signing
Murray S. Kucherawy
msk at cloudmark.com
Fri Oct 15 10:04:22 PDT 2010
> -----Original Message-----
> From: ietf-dkim-bounces at mipassoc.org [mailto:ietf-dkim-bounces at mipassoc.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.
More information about the ietf-dkim