On Tuesday, May 30, 2017 10:21:14 AM Seth Blank wrote: > On Tue, May 30, 2017 at 9:39 AM, Scott Kitterman <[email protected]> > > 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 <[email protected]> > > wrote: > > On May 28, 2017 11:27:35 AM EDT, John Levine <[email protected]> wrote: > > >In article <[email protected]>, > > > > > >>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 > > [email protected] > > https://www.ietf.org/mailman/listinfo/dmarc _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
