Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc7001bis-03.txt

[Hector Santos <[e-mail]>]

Some comments

On 3/9/2015 5:32 PM, [e-mail] wrote:
>
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>   This draft is a work item of the Applications Area Working Group Working Group of the IETF.
>
>          Title           : Message Header Field for Indicating Message Authentication Status
>          Author          : Murray S. Kucherawy
> 	Filename        : draft-ietf-appsawg-rfc7001bis-03.txt
> 	Pages           : 46
> 	Date            : 2015-03-09
>
> Abstract:
>     This document specifies a message header field called Authentication-
>     Results for use with electronic mail messages to indicate the results
>     of message authentication efforts.  Any receiver-side software, such
>     as mail filters or Mail User Agents (MUAs), can use this header field
>     to relay that information in a convenient and meaningful way to users
>     or to make sorting and filtering decisions.


For sentence #1,

      .... indicate the results
      of different message authentication efforts.

or

      .... indicate the results of any internal message
      authorization and authentication efforts.


I was under the impression that this header can only be "trusted" 
internally, essentially by the creator to be used by the backend 
"receiver-side" software or even at the UI hosted presentation?

The DKIM/ADSP/DMARC/SPF/OTHER machine domain host name creating this 
header needs to be trusted.

The main reason I say this is because the first time I began to use 
this for DKIM, I also used it for ADSP, Not SPF, nor ATPS.  SPF 
already had an internally produced and most importantly trusted result 
header (Received-SPF) and AUTH-RES wasn't quite ready to pass all the 
essential, different A/A protocol process parameters information being 
done, including SPF and ATPS.

So I created the fields I needed.   Since it would intended for 
internal consumption, other consumers like RFC-based Offline Mail 
Readers/Writers, these offline MUAs should not rely on it.

Is this still true?   If so, what are the rules for this?  How about 
different AUTH-RES from different processing host?

As a related tech note,  does the latest work reflect all the 
essential information needed for?

   DKIM
   DMARC
   SPF

Is it ready for indicating 3rd party results?

Does it still support ADSP or its obsolete in the new AUTH-RES as well?


-- 
HLS