[mail-vet-discuss] Last Call: draft-kucherawy-sender-auth-header (Message Header Field for Indicating Message Authentication Status) to Proposed Standard

[Dave CROCKER]

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