On 7/7/2011 6:57 AM, Murray S. Kucherawy wrote:
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.
well, it keeps the thread going...
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.
Huh? You mean that listing examples is not the same thing as specifying
directives or even similar to implying obligation?
You mean, an example is merely and example of what is possible? As in...
example.
gosh.
(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.
It might make a great deal of sense to do it here, if we were specifying a
tightly integrated, inflexible, and self-contained end-to-end reputation
service.
But since we aren't, modularity of specification scope is the norm for a reason.
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?
The word "reliability" has no meaning in this context. On the other had,
misunderstandings about implied or actual data validity is /exactly/ the issue
this text is /intended/ to cover.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html