security guys get particularly skittish about mechanisms that are, themselves,
explicitly about security. it's not that the caveats should not also apply to
examples such as the one JD cites. rather it's that if there is a claim that
the mechanism pertains to security (control, information, whatever) then they
press for very, very careful statements about purpose, use, limitations, etc., etc.
From what we saw with the original DKIM threats analysis document, this can be
carried much too far, but this review doesn't seem to cross that line into
outright silliness. Maybe not the most consistent application of demands that
one might like, but not silliness, either.
d/
SM wrote:
At 16:26 29-01-2008, J D Falk wrote:
Have the same concerns been raised in other WGs for the possibility that
somebody might hack into an IMAP server and modify messages there?
I thought of that as I read that part of the review. The difference is
that this header introduces the element of trust.
Regards,
-sm
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html