This might be a non-issue, but we're asking this question specifically because we've run into an implementation issue within openarc that feels weird and seems like a matter the WG may want to weigh in on.
Our expectation is that, for any given ARC Set n, AMS[n] would cover AAR[n]. Currently in openarc, AMS[n] covers all previous AAR[1..n-1] but *not* AAR[n] because AAR[n] isn't created until substantially later in the flow. Technically, this behavior is within spec as defined in https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-03#section-5.1.2.1.1 : Participants may include any other header fields within the scope of the ARC-Message-Signature signature except that they MUST NOT include ARC-Seal headers fields. In particular, including all DKIM-Signature header fields and all ARC-Authentication-Results header fields is RECOMMENDED. Is it worth guaranteeing that, if signing AARs, AMS[n] must cover AAR[n]? Or is this irrelevant because AS[n] is required to cover AMS[n] and AAR[n]? But if so, why recommend the AAR be covered by the AMS at all in the first place? While the differences between these two assertions appear to be benign (AAR[n] is always signed by AS[n], so whether or not it is in AMS[n] shouldn't matter), the spec leaves room for confusion about the right thing to do. What was the original intention here and does this need clarification? -- [image: logo for sig file.png] Bringing Trust to Email Seth Blank | Head of Product for Open Source and Protocols s...@valimail.com +1-415-894-2724 <415-894-2724>
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
