[mail-vet-discuss] Last Call: draft-kucherawy-sender-auth-header (Message Header Field for Indicating Message Authentication Status) to Proposed Standard
dcrocker at bbiw.net
Mon Dec 1 21:16:51 PST 2008
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
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.
More information about the mail-vet-discuss