Re: [dmarc-ietf] Eric Rescorla's No Objection on draft-ietf-dmarc-rfc7601bis-04: (with COMMENT)

"Murray S. Kucherawy" <> Sun, 06 January 2019 02:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 69D41130EE8; Sat, 5 Jan 2019 18:21:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 9e9rBOjQD9Nv; Sat, 5 Jan 2019 18:21:04 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2095012D4E7; Sat, 5 Jan 2019 18:21:01 -0800 (PST)
Received: by with SMTP id c19-v6so35413265lja.5; Sat, 05 Jan 2019 18:21:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=VqEKFCgw25hqkLLVnHKBLo/CW/BS8ZVbZnTn5Fcxpww=; b=mEPtEPU4fGkMEMNDLpl7cV4apO6ZW6KhSPNTJn5Q5AZEGWM5L+fPhNL47mhz9+pzZc nt6xf1jw64PFhov4reRKbSw2Imf3S4bOqk6ybW/nnLnQOaewm5BFCRm8saFgyqARxeq3 OiziEMTREix+eAUnhr5k+takFCqaA2qG66Yd/8Lw2lnklLhQwIFtDDZMfbfrnCOF/M1M WP66Yh2KPXCb87PIjV62o5UqAW6Gvn+tXW+Ly1I2mbE4MkODSjBV75LLTPzJcZaJcRZb 8a2faCOvDytTHjDQaygVIfRxOOf+yFrGXpL/c5o4gyodjKNrF0AGymm7lxEjc71KxKmT 1w0g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=VqEKFCgw25hqkLLVnHKBLo/CW/BS8ZVbZnTn5Fcxpww=; b=b4IP5rCviYFmHlmP4sh6ELoWPg6P1ppXbN7Lrhk7BPRHGQT2DXMzC65JF/HLdx/uua HRGpFXjQHNtc6+3pK70QjFgFfMTEUYEak/sonzoJ0GB8197axOTnQHB5Tiu83cRXumfc tHgjZTJtYwk8+kjCyqIQalBVRTwv4V0a3yrTISbJuN6brbR2EFQv5xMlm4VaIBlo4aCk 9y3MFMOdue9ZWChjSeT+fcP06FqiTQMYYN1YTZJUH4tfBlYGe+uASTd3jjQsOVgma8oH Xxqt9+4R+A8L+6qLf+QZWsUsDF81Nc65xOinfiM97QQptIzuD3KsuEKQAEHbm09q+aZt F4lg==
X-Gm-Message-State: AJcUukcz/LXqt5cRSUyxuV3uETGBo+YqcKFh1vq+YeXkcFT9a0UJPhb7 FQDGTjjIxrkCDWxXwl0xSRTZbNUwsosy1XJHNkw=
X-Google-Smtp-Source: ALg8bN7QETYHJj9pLXeP2KzQ3+GpBxwBJdJNhqZMvVDFOWdhwe2UH9nbn/fxcgTN+7DwluWRfDc1Bkj1LgePBX7iRsI=
X-Received: by 2002:a2e:750a:: with SMTP id q10-v6mr28046657ljc.39.1546741258798; Sat, 05 Jan 2019 18:20:58 -0800 (PST)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: "Murray S. Kucherawy" <>
Date: Sat, 05 Jan 2019 18:20:47 -0800
Message-ID: <>
To: Eric Rescorla <>
Cc: The IESG <>, Tim Draegen <>, IETF DMARC WG <>,,
Content-Type: multipart/alternative; boundary="0000000000004a560d057ec0c34a"
Archived-At: <>
Subject: Re: [dmarc-ietf] Eric Rescorla's No Objection on draft-ietf-dmarc-rfc7601bis-04: (with COMMENT)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 06 Jan 2019 02:21:07 -0000

Hi Eric, thanks for your comments and sorry for the delay in replying.

I've applied all of your comments except those below, for discussion:

On Tue, Nov 20, 2018 at 4:46 PM Eric Rescorla <> wrote:

> S 7.10.
> >      processing of these is outside of the intended scope of this
> document
> >      (see Section 1.3), some early guidance to MUA developers is
> >      appropriate here.
> >
> >      Since MTAs are unlikely to strip Authentication-Results header
> fields
> >      after mailbox delivery, MUAs are advised in Section 4.1 to ignore
> I think you want to be stronger than "are advised to"

I changed "advised" to "warned"; is that adequate?  It's referring to a
SHOULD in 4.1.

S 1.2.
> >      Thus, this document defines a "trust boundary" as the delineation
> >      between "external" and "internal" entities.  Services that are
> >      internal -- within the trust boundary -- are provided by the ADMD's
> >      infrastructure for its users.  Those that are external are outside
> of
> >      the authority of the ADMD.  By this definition, hosts that are
> within
> >      a trust boundary are subject to the ADMD's authority and policies,
> This seems like a reasonable design, but not the only one. For
> instance, Gmail might attach these headers, but I don't think of my
> MUA as being subject to its authority and policies.

The MUA in the Gmail case is Gmail itself, isn't it?  Or at least their
client?  Or are you referring to some IMAP access to it?

S 1.5.3.
> >      agents, assign (some) responsibility for the message (which implies
> >      authorization), and ensure that the listed portions of the message
> >      were not modified in transit.  Since the signatures are not tied to
> >      SMTP connections, they can be added by either the ADMD of origin,
> >      intermediate ADMDs (such as a mailing list server), other handling
> >      agents, or any combination.
> I'm not sure how persuaded I am by this terminology. However,
> regardless of that, this claim about SPF seems problematic in the
> sense that you could have an intermediate MTA decorate the message
> with the incoming IP address (in some unspecified way)  but then have
> the terminal MTA do the SPF validation.

Right, that's a property of SPF: It only evaluates the latest ("connecting"
in that paragraph) hop, while DKIM often survives end-to-end irrespective
of who's relaying it in to the local ADMD.

S 2.2.
> >      combination of these can be applied.
> >
> >   2.2.  Formal Definition
> >
> >      Formally, the header field is specified as follows using Augmented
> >      Backus-Naur Form ([ABNF]):
> An example would be kind of helpful here.

I put in a forward reference to the Examples section instead.

S 2.4.
> >
> >      This ptype existed in the original specification for this header
> >      field, but without a complete description or example of intended
> use.
> >      As a result, it has not seen any practical use to date that matches
> >      its intended purpose.  These added details are provided to guide
> >      implementers toward proper use.
> This text is odd in a bis draft, because "the original" is not 7601 or
> 7001.

Would actual RFC numbers be better?  The point here is that the original
(5451) didn't do a great job of explaining how this works, and then the
intervening versions (7001, 7601) didn't fix it.  We're finally fixing it