Jim Fenton wrote:
I'm mostly concerned that some users of the A-R header field will see
the different result, and feel that they need to take different action.
I'd be happy with a non-normative note pointing out the problems with
User?
If you mean human user, then that's the real problem. Humans don't see such
header fields unless they look for them. And there's an infinite amount they
will see and not understand. If you mean MUA filtering software, then it will
either know how to process the data or it won't.
None of this realm of mechanism or data is designed for end-users.
In terms of modeling, this header field is a form of inter-process
communication, from an authentication validator to a reputation assessor.
Header field removal
I suggested additional text cautioning about (sec 5 paragraph 2)
removing all auth-results header fields. I can picture that some users
might want to trust Authentication-Results from specific domains (I
might trust ietf.org, for example) especially if it was signed as
described in section 8.1 #1.
A MAY does not prohibit such trust. Rather, it establishes the
normative point of view that retaining the file, as it crosses a trust
boundary, carries danger and it really is ok to remove the sucker.
Adding some text to say that it might be ok to retain it is fine, too.
Adding explanatory text suits me as well.
Not bad for an initial round of notes: One continuing clarification/debate.
One entirely open issue. One agreement.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html