Re: [dmarc-ietf] Last Call: <draft-ietf-dmarc-rfc7601bis-03.txt> (Message Header Field for Indicating Message Authentication Status) to Proposed Standard

"Murray S. Kucherawy" <> Sat, 03 November 2018 04:44 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7CEB1130E06 for <>; Fri, 2 Nov 2018 21:44:55 -0700 (PDT)
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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 56UdGxXPSrYE for <>; Fri, 2 Nov 2018 21:44:53 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::129]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 600CB130E0E for <>; Fri, 2 Nov 2018 21:44:53 -0700 (PDT)
Received: by with SMTP id m18-v6so2640170lfl.11 for <>; Fri, 02 Nov 2018 21:44:53 -0700 (PDT)
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=cQXcwD+/LhcUOxv+aClwt8jCpne8+ne74GOqgRqK4dU=; b=gSj4Kr4xvhxLyU/OnkDdB3r106wb+JTh6Z5+raRKKsDJf6DSjmatBf+KEGI8CprJ/v 30J1qz0iV7GTZhNpoJnM3VtwxVHoflpcedJ2aO1DGh2Qx2lcPS8Z6ptkJ8Fan0vSJnZT EUikYeQH4eTJLnE2Of2ciVWnQ3gnT2IQnKa5RgUu9RqADuI4IAJzfVeV6ElhmrCkV7iM t/9UYqgBcDbzxXewLJHqPl4ZIPlaaLdqUb/BLNy37/3i+hWF0Vgm8ixleq5+vmYWZkOq GIY3Ag6YxURTwB1olHcdDvlXtNzP4i/yNmAVX6lzozTeoFBECOySGibZbAclIY0RE3ly MIZg==
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=cQXcwD+/LhcUOxv+aClwt8jCpne8+ne74GOqgRqK4dU=; b=H8sDkV+qPzP9DLnIR/6CAx3EQfeYZHG9jTYy4Bzv1cG2HoiHvRblQqCgzviK/58dNt tzYQY09JJE4qmwe6UiveD9aQsNpyonC5ZNWmpd2Hx7JdDaWMUvuBdzwrzzyuIPIjb0dz cjLLFdbWOdu0/7dEBosf+NWOzHOKyne4sMpO8iiRDXjLnWJRcBMQbrqn7G7OQDqIXpHa 7Ntxncl4rNXerpfmrYBQa7S+bNh8v/fl1TB6qLMINLjS+kT4STdtU8OWGIL/orOTstyQ jzk64I5LIoGuL6UI7/h4b/zv3WvpOTOl/+anMg4LcgvqCCVSYsUz4OYO8qNjCdBplPxE DCVg==
X-Gm-Message-State: AGRZ1gL8OrgQguOnc4Dt53gCVXdsbFuUQiozGH9IBQgJvkq3BZCPmOde N3td+x/ueeDm6KB/uzY5mWJ2Ty6bAs94nzbSBfA=
X-Google-Smtp-Source: AJdET5cEjWcFaYFzY1fpopsCAltLRshITcufxEsxmYfdXABNg6cN3YN4nZGBWi6UF+dCuteGQqkViRbewZpFEMStFbU=
X-Received: by 2002:a19:6d0e:: with SMTP id i14-v6mr8477698lfc.57.1541220291455; Fri, 02 Nov 2018 21:44:51 -0700 (PDT)
MIME-Version: 1.0
References: <> <4532875.QxLTiTrTcc@kitterma-e6430>
In-Reply-To: <4532875.QxLTiTrTcc@kitterma-e6430>
From: "Murray S. Kucherawy" <>
Date: Sat, 3 Nov 2018 13:44:39 +0900
Message-ID: <>
Subject: Re: [dmarc-ietf] Last Call: <draft-ietf-dmarc-rfc7601bis-03.txt> (Message Header Field for Indicating Message Authentication Status) to Proposed Standard
To: Scott Kitterman <>
Cc: ietf <>
Content-Type: multipart/alternative; boundary="000000000000fe31000579bb4f2b"
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 03 Nov 2018 04:44:56 -0000

On Sat, Oct 27, 2018 at 2:19 AM Scott Kitterman <> wrote:

> As written, is it appropriate for this draft to obsolete RFC 7601?  Should
> it
> update it instead?
> In the Email Authentication Parameters registry [1] there are 63
> parameters
> that use RFC 7601 as the reference for their definition.  They are not
> replicated in this document.
> As it stands, that would result in the registry using a historic document
> for
> definitions in an active registry.  Is that OK?
> Assuming it's not (because if it is, then there's no issue to discuss),
> there
> are two solutions I can suggest:
> 1.  Change this draft to update RFC 7601 rather than obsolete it.
> 2.  Add the missing parameters from RFC 7601 to this draft and update the
> registry entries to use it as the reference.
> I think the former is easier and the latter a bit cleaner for implementers
> to
> have fewer documents to sort through.  I don't have an opinion on which
> would
> be better.

Yeah, good catch.

I'm inclined to change this to "updates" rather than "obsoletes".  It's
otherwise a lot of stuff to copy over just for the sake of making keeping
this as an omnibus document.  I'll do that unless someone makes an argument
for the other choice.

Are there any registry entries you think that should reference both
documents?  IANA lets us do that for registrations for which an implementer
should be pointed to more than one reference.