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

"Murray S. Kucherawy" <superuser@gmail.com> Wed, 31 May 2017 23:01 UTC

Return-Path: <superuser@gmail.com>
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 679E2128B8E for <dmarc@ietfa.amsl.com>; Wed, 31 May 2017 16:01:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.599
X-Spam-Level:
X-Spam-Status: No, score=-0.599 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nFBkqQ__rfcS for <dmarc@ietfa.amsl.com>; Wed, 31 May 2017 16:01:27 -0700 (PDT)
Received: from mail-ua0-x231.google.com (mail-ua0-x231.google.com [IPv6:2607:f8b0:400c:c08::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD32E129459 for <dmarc@ietf.org>; Wed, 31 May 2017 16:01:26 -0700 (PDT)
Received: by mail-ua0-x231.google.com with SMTP id u10so18271666uaf.1 for <dmarc@ietf.org>; Wed, 31 May 2017 16:01:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=JrjJon4FpEyKNojgQmphqpGpkBU9jEnu0T1U8gd1n8Y=; b=UvVw1aDs5LZ5R1u99a6aP/0nTLS0A6IsdWg4wOIaQ6Dv7ZY4Ewf+Q+ePcqeckfJNxL WB4R7LoH4JiTsmTOb+EAGjBGgVOHgowM7Yfv6NR3JUiTmJcVeBfWTkBnRDgVUdQ2NUs8 1N+sCdTI5WXf8okLc48nMmCqIBXSXmUi4mx0r5SneSuOGPJB+lTGBRKnMQvaXF/JTwoB veiSdkX+t8fTIpx0JPdYongJ0WNwjjmBzYuyDVA4hntJEp4FXBWfrLmS0Oi+z95W2NYr MylN0SYKW2Y0b/Pg07NWXCGvsthVPgZdLFe9rz+PoLM7LcU+UoZg2N/TjMhoSg8/OOMI B9yA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=JrjJon4FpEyKNojgQmphqpGpkBU9jEnu0T1U8gd1n8Y=; b=kfrKLKBxvmQvfMWI2HF+HoAbn70/B+5MxWAG+jNTbtYwtf4hx6g1tqZ2dMWayXNi8z JV1gh5H4grG20TqNnwBLRhkJXu7dP+oC3CYelr8PfdPPgksz1Wsz1Gvm5yECjwAgxtXn V/+Z+4x5Kx16WyAfRhquLJgrHJ+O8Mx1YDxB1m6wNdj6K/91Z9WdgCGKTmboTempn77k X/9hCqIB1/d1fTLFXHzudl5pM5/oVrX0vnx4CGZoTMJpogRKcIW0i4gkeiSvVrJ8CR48 XwLxgQhgqavZdX+OfA4lp/sqm63SFdeeZ/FsToBCDOFhNFLXDFD+jSnMcFnoKa4GVx+S dCuw==
X-Gm-Message-State: AODbwcBdAFbmYYXrlmur5GDAJG4dxZt/Dro/SFmR+FM7naL7cvsXNmdU 5AFEhK1+D/j0kOwhuUxjUAEhDThAr1KW
X-Received: by 10.176.69.65 with SMTP id r59mr15265047uar.80.1496271685942; Wed, 31 May 2017 16:01:25 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.103.25.69 with HTTP; Wed, 31 May 2017 16:01:25 -0700 (PDT)
In-Reply-To: <3073712.x93XL1H1LP@kitterma-e6430>
References: <alpine.OSX.2.21.1705242026410.29429@ary.qy> <4BC08AA6-02AE-4186-B0DB-ED773A35809C@kitterman.com> <CAOZAAfN2E--bpMOrpFWRs3gAEMWM8ziCd_o9U3sh7+87PNE_Gg@mail.gmail.com> <3073712.x93XL1H1LP@kitterma-e6430>
From: "Murray S. Kucherawy" <superuser@gmail.com>
Date: Wed, 31 May 2017 16:01:25 -0700
Message-ID: <CAL0qLwbyDWjEgjDAnNJykZxhzLwnt_q+NvNs5qLy6LV2kJXQZQ@mail.gmail.com>
To: Scott Kitterman <sklist@kitterman.com>
Cc: "dmarc@ietf.org" <dmarc@ietf.org>
Content-Type: multipart/alternative; boundary="94eb2c0b98985402a00550d9e6e6"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/YtW9JTew2EdM7ZmB2HNF8Yl2tw0>
Subject: Re: [dmarc-ietf] Guidance around constructing an AAR when multiple AR headers are present?
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" <dmarc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmarc>, <mailto:dmarc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dmarc/>
List-Post: <mailto:dmarc@ietf.org>
List-Help: <mailto:dmarc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmarc>, <mailto:dmarc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 31 May 2017 23:01:28 -0000

On Tue, May 30, 2017 at 10:33 AM, Scott Kitterman <sklist@kitterman.com>
wrote:

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

I'm leaning toward MUST using Seth's language.  It seems to me SHOULD
leaves an interoperability hole, plus you'd have to come up with some
sityations where not doing so makes sense that are stronger than "I didn't
want to."

-MSK