Re: [dmarc-ietf] Question regarding RFC 8617

Dave Crocker <> Fri, 08 November 2019 00:13 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 74B13120147 for <>; Thu, 7 Nov 2019 16:13:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Km-5X1Kgv9ZN for <>; Thu, 7 Nov 2019 16:13:10 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B294C1200C4 for <>; Thu, 7 Nov 2019 16:13:10 -0800 (PST)
Received: by with SMTP id a14so3714030oid.5 for <>; Thu, 07 Nov 2019 16:13:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=oCyF5onVtgxWkaw+tVgf2ltwR0VaiakJbYrZo1lAI8o=; b=CRGtmN9wctEHvgbVtEdjn2PY3yT+GBfgKy0+k0RjrMTGug6y7qpxlb0+hOI0bYBJ/4 tiEMb+bTV4vQXPm9uRAIJAEoFOAuM0AgEHn6mSbPPHJJvD7n1o0dCMqfRyGvzqUfzIsH pdHbDMM9Ai9BZh1pzlPAgVhqB76RMuZG8gzxRTPE7YIDGaJCLaI4MclZMLvweEHRiEMY 10Ir1dJ1ZTESDH6/hSzkhTiy5bHqcKc3ssUHx1D47LEtNFq+E6fhf7lr9/aaOR7HJBlK GDWYEGiCFTiYcW0cD70Al71K6qkR7WQcH7dt8PwoYfUP9sd2c7IPQ7NgXSlzXRQhO/gc kapA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=oCyF5onVtgxWkaw+tVgf2ltwR0VaiakJbYrZo1lAI8o=; b=CssKCuWKvlG7O3/UEpaVbhJJKAaEcZqTavGBtmU1oVoyHONi6Js0nbKtKVA5SFTwE9 /97ygB7Lk4QpEUL8d3DnXjoRHQy4NQw1SUO3I7rLv0bUlCmjqMH7EKfkZd5bH4tjoOh0 D+A46v/acZ2cqa1MpEmd0IDX7dbCcgsVW5v2FPv36dXk6CtzAEjFo3qo2voI7tw4CkjA WNhD+ffzTuAR2RGjOd6UkNq8hFTcx7ABB1YU1L1zGNOgGp2byzVtBhVDyk4rrHpFCVlH VY/lu4H3rVy+9PWmzRUBZzPCRAFA+5j8A5shvaipIsgpH5hdgZERe9Hjusj2JdRMdDBp DkeQ==
X-Gm-Message-State: APjAAAWgh+YwfFGXfq05cz5a2Re/+eoj+MtVwzj46ulMfM9SJuvxeZ/G 5hZHD/2UfgSeaHc6/hEO1S0KIqgw
X-Google-Smtp-Source: APXvYqyU0ULNc36X2UKLQTBbEF+031sJC2Yh+7RlQBc9t7p07BS6DWostBV38SqQlb/CRwMzGsiPJw==
X-Received: by 2002:aca:3e8a:: with SMTP id l132mr6082441oia.146.1573171989939; Thu, 07 Nov 2019 16:13:09 -0800 (PST)
Received: from ?IPv6:2600:1700:a3a0:4c80:911f:9579:419e:7fa6? ([2600:1700:a3a0:4c80:911f:9579:419e:7fa6]) by with ESMTPSA id c23sm1088872oiy.20.2019. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 07 Nov 2019 16:13:09 -0800 (PST)
To: Brandon Long <>
Cc: Brandon Long <>, "Kurt Andersen (b)" <>, "" <>, "Weist, Bill" <>
References: <> <> <> <> <>
From: Dave Crocker <>
Message-ID: <>
Date: Thu, 7 Nov 2019 16:13:07 -0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <>
Subject: Re: [dmarc-ietf] Question regarding RFC 8617
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: Fri, 08 Nov 2019 00:13:13 -0000

On 11/7/2019 3:16 PM, Brandon Long wrote:
> On Thu, Nov 7, 2019 at 9:28 AM Dave Crocker < 
> <>> wrote:
>     On 11/6/2019 9:43 AM, Brandon Long wrote:
>      > What's more, the point of including Subject and other mutable
>     headers is
>      > the same as it is for DKIM, those are the headers which are
>     important to
>      > the receiver, so they should be validated.
>     This being a technical list, I'm going to get picky and note that DKIM
>     does not 'validate' those fields.
>     There is a derivative data integrity benefit, between signing and
>     validated, for such fields, but that is quite different from any claim
>     that the contents of those fields are 'valid'.
>     Some signing sites have much more stringent uses of DKIM than are
>     provided by the standard.  That's fine, of course, but it has
>     nothing to
>     do with the standard.  Hence any receive-side reliance on such signer
>     data validation is outside the DKIM standard.
> I should have said "covered by the signature".
> And I think they are important to both the sender and receiver, your DKIM
> RFC calls them "core to the message content" and so the "core of the
> message is valid"... which is different than validated, of course.

yeah.  really unfortunate language.  over the course of different DKIM 
docs, I kept finding language that needed to be /much/ better.  Only 
some of it now is.

That's not one of them, since the context was of that bit of text was 
meant to assert transit integrity rather than data 'validity'.  sigh.

At least there is some comfort that that section makes clear it's 
concern is replay protection, rather than semantic validity.

Dave Crocker
Brandenburg InternetWorking