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

["Murray S. Kucherawy" <[e-mail]>]

On Sat, Mar 14, 2015 at 3:53 PM, Hector Santos <[e-mail]> wrote:

> For sentence #1,
>
>      .... indicate the results
>      of different message authentication efforts.
>
> or
>
>      .... indicate the results of any internal message
>      authorization and authentication efforts.
>

They're not necessarily internal checks (where "internal", I assume, means
"done by my ADMD").  You could decide to trust an upstream check from your
ISP, for example.


> 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?
>

No, that's never been the case.  Going back as far as RFC5451 Section 5,
we've always allowed for the possibility of trusting information from
outside.  You just have to decide you believe whatever the outside source
is telling you.


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

Yes, that's the point, not that it has to be internal.


> 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.
>

A-R predated ATPS, so they've always been compatible.  As for Received-SPF,
the whole reason this was introduced is because SPF created a header field
for recording its results, and DomainKeys proposed one as well.  Rather
than having a different one for every method, it made sense to create one
extensible one for this purpose.


> 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 by "this" you mean internal consumption, then yes, mostly; it's intended
for consumption by downstream agents (filters and MUAs, mainly) that are
able to figure out which ones they believe.


> If so, what are the rules for this?
>

Several sections of RFC5451, such as 2.3, 4.1, and 7, talk about when and
how to consume the header field.  All of this is carried forward into
RFC7001 and now this document.


> How about different AUTH-RES from different processing host?
>

Same answer.


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

Yes.

Is it ready for indicating 3rd party results?
>

The only supported third-party reporting scheme is ATPS, but it hasn't seen
much in the way of real world deployment.  None of the others have
documents attaching them to Authentication-Results.

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

This draft doesn't cover them because ADSP was declared Historic.  However,
previous versions did, so "dkim-adsp" is still a registered method (though
it's marked "obsolete").  I think this draft should actually change their
entries to "deprecated".

-MSK