[ietf-dkim] Final update to 4871bis for working group review
Murray S. Kucherawy
msk at cloudmark.com
Thu Jul 7 06:57:46 PDT 2011
> -----Original Message-----
> From: ietf-dkim-bounces at mipassoc.org [mailto:ietf-dkim-bounces at mipassoc.org] On Behalf Of Alessandro Vesely
> Sent: Thursday, July 07, 2011 4:56 AM
> To: ietf-dkim at mipassoc.org
> Subject: Re: [ietf-dkim] Final update to 4871bis for working group review
> I'd s/to be liberal/to be exceedingly liberal/ (we don't want to
> revise Postel's statement, do we?)
You're either liberal in your application of the RFCs, or you're not. I don't see how adding that word improves things here.
> > DKIM signs and validates the data it is told to and works correctly.
> > So in this case, DKIM has done its job of delivering a validated
> > domain (the "d=" value) and, given the semantics of a DKIM signature,
> > essentially the signer has taken some responsibility for a
> > problematic message. It is up to the identity assessor or some other
> > subsequent agent to act on such messages as needed, such as degrading
> > the trust of the message (or, indeed, of the signer), or by warning
> > the recipient, or even refusing delivery.
> I'd omit any allegation on what an assessor's needed actions might be.
"Such as" makes it clear these are only possible actions (and the obvious ones). It's not an exhaustive list.
> (Actually, we'd need yet another policy or authentication method in
> order to allow the outcome of an identity assessor to be formally
> expressed. Without it, the quick-n-dirty approach of degrading the
> trust of a message by tampering with its DKIM verification's results
> may seem the easiest remedy --much like what Doug et al. proposed.)
If the role of the identity assessor is reputation, and we decide later that we want reputation to be relayed to downstream agents, we can extend RFC5451 by such a registration then. It doesn't make sense to do it here though.
> > An agent consuming DKIM results needs to be aware that the validity
> > of any header field, signed or otherwise, is not guaranteed by DKIM.
> Please, s/validity/reliability/: someone might believe a field is
> valid if it retains the value that was given to it originally.
Isn't that conclusion precisely what this sentence is countering?
More information about the ietf-dkim