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

Seth Blank <seth@valimail.com> Wed, 24 May 2017 23:34 UTC

Return-Path: <seth@valimail.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 B5F56128CDC for <dmarc@ietfa.amsl.com>; Wed, 24 May 2017 16:34:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=valimail.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 hotCqygeKMbr for <dmarc@ietfa.amsl.com>; Wed, 24 May 2017 16:34:26 -0700 (PDT)
Received: from mail-qt0-x22e.google.com (mail-qt0-x22e.google.com [IPv6:2607:f8b0:400d:c0d::22e]) (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 3AEEA12751F for <dmarc@ietf.org>; Wed, 24 May 2017 16:34:26 -0700 (PDT)
Received: by mail-qt0-x22e.google.com with SMTP id f55so168447251qta.3 for <dmarc@ietf.org>; Wed, 24 May 2017 16:34:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Aki/+oChF5XCKSBveh82Dx56hEtH2o8TyCUp+bmd0j8=; b=YIGOWdu7g2XA3fJOEYU4cLdbeyfX7hjh8Z9fMiAaeiI+asiZ1N9+BqsOVBYrSWApB7 VVPteEFMitDmZSurG62KezA/y3nSAlxZrwnw/ydseG9UByKbbHcwE4tyfUIq2fyw1RXl xBr6SGPQCgMeadj8x44/wk7oVvzjvtwsmab+xsNYT1KWRvmMU0Cf8kmqngvL4bhuYNNI TUaDdw+KXjsR2whTJUazUQAyJHDdkiQ5AIDorxb8u4xgBH+/KddzT24YCQjxqqs35NTw RW3jYBnqsEboZmFeiiLUyhEwveLfw/oTSoGxcWw8+yPZXbQns/lP3KFRuJ1u67v4FSc/ zCbw==
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=Aki/+oChF5XCKSBveh82Dx56hEtH2o8TyCUp+bmd0j8=; b=XQIeIzkUcbVuW/fSZRPS1DivKPXo4LL7IPiK8Ib60eZPP2YVXvj98gCVdIWJCuRhut QwJFFWvHltRnDniYP+n7f6W9JqC46KfBjfH6yqLeMhYIZWfFj1e92Fn4s91elLFwgbC/ 2m7RHw7jdRtJ/L68v1++zVDiu+S441Y5rtn/1JwHkrfWBgP+6FH49Ln3ftNTwFfecXc/ wRtPQtsLlvnsYwjZPRkTRxjq5kJ9/N9vYEVYi8gk/S9kljwuqjdMu3Wtk0uDJ72hNwT0 odLWgNUmUBHXxIGWErYFs0KYlhbFyIipxu931OPJfQgKtmoGOenilVWDaML0CTqs61Ce +3Yw==
X-Gm-Message-State: AODbwcCOqcJ3UAXyCGCn8jnbmpoPVRZQ92tYc+/yoe2Y18hkMQuwNJjm 7myxZGIj/wVr3uFxs06+HlG5DxbcAWED4cE=
X-Received: by 10.200.47.161 with SMTP id l30mr39336728qta.153.1495668865258; Wed, 24 May 2017 16:34:25 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.200.42.242 with HTTP; Wed, 24 May 2017 16:34:04 -0700 (PDT)
In-Reply-To: <CABa8R6v4oGpFYeO8qGaKpbocr6f8V_+Hf7XavZ0h12d1RgWLBQ@mail.gmail.com>
References: <CAOZAAfOsRrQF2M3NzcB3h2Tc03mtFfG8mOJ0pqU+_cx=whcBLQ@mail.gmail.com> <20170524192617.36732.qmail@ary.lan> <CABa8R6v4oGpFYeO8qGaKpbocr6f8V_+Hf7XavZ0h12d1RgWLBQ@mail.gmail.com>
From: Seth Blank <seth@valimail.com>
Date: Wed, 24 May 2017 16:34:04 -0700
Message-ID: <CAOZAAfOrHku8x9UmxtkFNpRPdfgAzn2B2Kq6=Wngwk7bY1YpWw@mail.gmail.com>
To: "dmarc@ietf.org" <dmarc@ietf.org>
Cc: John Levine <johnl@taugh.com>, Brandon Long <blong@google.com>, Kurt Andersen <kboth@drkurt.com>
Content-Type: multipart/alternative; boundary="001a113789126a681605504d8bd0"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/g9AyG1Bl409R75gRO64AvGpBjMk>
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, 24 May 2017 23:34:29 -0000

On Wed, May 24, 2017 at 4:10 PM, Brandon Long <blong@google.com> wrote:

> I think the default using the open* libs is to do so, so probably.  OTOH,
> how to do so seems fairly obvious, I'm not clear on why doing so needs to
> be specified.  Being sure the spec specifies that only one is allowed,
> definitely.
>
> Brandon
>


Yes, the open* libs create multiple AR headers, there are even various open
source tools (like https://github.com/RunasSudo/combineAR) to combine them.

While addressing multiple AR handling in openarc (which was immediately
necessary when running it alongside opendkim and opendmarc), how to do so
was not explicit in the spec, hence the question.

Agreed that we're only talking about a single AAR per hop. Also agreed the
solution appears as straightforward as just combining all AR results from
your ADMD into a single one and then turning that into the AAR. But I'm
uncertain if that's the method the group thinks is appropriate and if
there's been any earlier conversation around this.

Regardless, there are already implementations that do this in different
ways, so I'd argue clarity in the spec is a good thing. Especially since
just grabbing an existing AR header might prove lossy in a way that makes
original message disposition impossible to determine for a final receiver.

If we're in agreement, I would suggest adding the following sentence to the
first paragraph of https://tools.ietf.org/html/dr
aft-ietf-dmarc-arc-protocol-03#section-5.1.3 :

"The AAR should contain all Authentication-Results results from within its
ADMD, regardless of how many Authentication-Results headers are on the
message."

I think between that and the third paragraph of the section, the above
"obvious" solution becomes the only possible solution allowed per spec.

Thoughts?

-- 

[image: logo for sig file.png]

Bringing Trust to Email

Seth Blank | Head of Product for Open Source and Protocols
seth@valimail.com
+1-415-894-2724 <415-894-2724>