Re: [dmarc-ietf] Guidance around constructing an AAR when multiple AR headers are present?

On Tuesday, May 30, 2017 10:21:14 AM Seth Blank wrote:
> On Tue, May 30, 2017 at 9:39 AM, Scott Kitterman <sklist@kitterman.com>
> 
> wrote:
> > On Tuesday, May 30, 2017 09:34:49 AM Seth Blank wrote:
> > > Resolved items:
> > > - Handling of multiple incoming AR headers (resolved, but language not
> > > yet in spec)
> > 
> > If this is resolved in favor of not handling multiple AR header fields
> 
> (which
> 
> > IIRC is the plan), then something needs to specify the combination is
> > required.  I think that something needs to be a DMARC document, not ARC,
> > because this is a requirement that's being imposed on all DMARC AR header
> > field providers regardless of if they care about or participate
> > explicitly in DMARC.
> 
> I believe the consensus in this thread was about adding the following
> sentence to the first paragraph of https://tools.ietf.org/html/draft-ietf-> dmarc-arc-protocol-03#section-5.1.3 , with added clarification that we're
> only talking about the current AAR[n]:
> 
> "The AAR should contain all Authentication-Results results from within its
> ADMD, regardless of how many Authentication-Results headers are on the
> message."
> 
> I don't think this needs a separate document, as I think it is very ARC
> specific because it's only about construction of the AAR header and making
> sure the proper information gets into it (since multiple AR headers are a
> reality in the wild, we just need a sentence on how to deal with them).
> 
> Or am I totally misunderstanding your point?
> 
> Seth

It at least, probably more likely, I'm misunderstanding.

At some point in the process, an AAR and ARC signature get created. Later, 
someone else has to validate them.

My point was that when you are on the signing end of this, you have to grovel 
through all the relevant AR header fields since there's nothing telling 
another doing new authentication the should combine them into the same field.  
Seeing sequence of AR fields for SPF, DKIM, and DMARC is quite normal.

I thought that what was being said was that the AAR contstruction process 
could assume a single AR field and that's not correct.  Now that I see it 
explained again, I see I was thinking one step too far back in the process.

So, I think it was my misunderstanding, although if you're doing to use the 
results of the AAR in the verification process and assume it's all in a single 
AAR header field, then I think that should be a MUST, not a SHOULD.

Scott K

> On Sun, May 28, 2017 at 8:53 AM, Scott Kitterman <sklist@kitterman.com>
> 
> wrote:
> > On May 28, 2017 11:27:35 AM EDT, John Levine <johnl@taugh.com> wrote:
> > >In article <8F87F9DE-C87E-406E-BA49-6AEA5DC17283@kitterman.com>,
> > >
> > >>Nothing other than potentially ARC requires multiple AR header fields
> > >
> > >for different authentication types to be combined.  These different
> > >
> > >>verification operations (e.g. SPF, DKIM, and DMARC) are generally
> > >
> > >performed be different processes that add their own AR field.
> > >
> > >Since DMARC needs the results of SPF and DKIM, how does that work?
> > >Does DMARC look at the A-R that the other two created or is there a
> > >side channel?  It occurs to me that a DMARC process has everything
> > >needed to make a header that combines all three.
> > 
> > snip
> > 
> > At least for OpenDMARC, if it's not doing it's own SPF check (which seems
> > odd to me because it's done after DATA, but it works), it will look at
> > multiple AR fields for both SPF and DKIM results.
> > 
> > Scott K
> > 
> > _______________________________________________
> > dmarc mailing list
> > dmarc@ietf.org
> > https://www.ietf.org/mailman/listinfo/dmarc