Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd

"Murray S. Kucherawy" <> Tue, 04 February 2020 21:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D357F120152 for <>; Tue, 4 Feb 2020 13:20:56 -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_HELO_NONE=0.001, 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 jJHbP0CYrMuv for <>; Tue, 4 Feb 2020 13:20:55 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::e29]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 422C012012E for <>; Tue, 4 Feb 2020 13:20:55 -0800 (PST)
Received: by with SMTP id x123so12475464vsc.2 for <>; Tue, 04 Feb 2020 13:20:55 -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=G5G2EKAzN6zJ9RKwmqnicxAo4/rLVFG72tAEcgL023k=; b=gPIZ3ldPJwVj6493p4xMB+TeQ4ay+G08YVrDDToeqY33rILD4v6AnYOBDhV3l1ySeT vaE+iII/UMsvZokB99P1HxSF/qJ5H4GJ3MQdANRZ4eMwIdgeAIpzPSGq5NkgDF+YXEBE +K2bF80CKZgpo9QDdxxmG6/YNqlEgUyuNoPCgcxipkc0q6Fsmo4sZf6ubDfYOgO5Dwq8 wxuhXIwz+4a+wt7QlRicjumhs4sS+UAAdRsE5y1l0W3Z5eJqT0iPYCsddq+s/uXevsrH xGnc3shFpMYQpLqTQhoBrpEZZtmqkZ7FCieZtiLO4jFKGiP9x/xCbqZqzwvFHEwwA/nw Hi6A==
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=G5G2EKAzN6zJ9RKwmqnicxAo4/rLVFG72tAEcgL023k=; b=eNJw6djbvx5WEkRYPuJqw4WxMFT2aTDq0cxVi8fZ7bZEB4n9FJwqSJzLlCxdEWDNen k/cQ1KFs6TezZpyEE0AM92zOpgkCGKCHTigwViZUK0YBpLfGOa7LpqICnMtDW/K0bSwj 1La8gdAKqSfy90gpDXdaXCYGOPnqGyDrL3iV+nZR6cnKNyPFNVLdYbzIjpvsF68iXAW7 9zzPHhs/xVfsIysZew0zIWlqkRIl3dSFmkGytuN6t0Fqdzjcowyse3UNMuxMOOMZ47w2 I7O8UXBLReytb2gERSJ9EKessWryFZ2lRr8wAcXGXB3KfMiGCW6Gp0ijqOnRLdtxMWsV DnjQ==
X-Gm-Message-State: APjAAAV2oJItqxHQqChGaEI0O8b4CyT20UOy+YkiKHgbyXwzkrPBh+ZX CZ00RiixH3iSB6qHqK4xekklgiCc3wMOwRN+IPk=
X-Google-Smtp-Source: APXvYqw6brpIXjMBPzZ5G1/SQpAuwltCatg/X1ZbhczbzUbUFTDqSsHpSTXmsMVDVkRzPh0RrKi+omNeOKzUkVXGPoc=
X-Received: by 2002:a67:ce86:: with SMTP id c6mr20752696vse.7.1580851254214; Tue, 04 Feb 2020 13:20:54 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: "Murray S. Kucherawy" <>
Date: Tue, 4 Feb 2020 13:20:40 -0800
Message-ID: <>
To: Dotzero <>
Cc: Dave Crocker <>, IETF DMARC WG <>, Alexey Melnikov <>
Content-Type: multipart/alternative; boundary="0000000000007343c2059dc69d6a"
Archived-At: <>
Subject: Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd
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: Tue, 04 Feb 2020 21:20:57 -0000

On Tue, Feb 4, 2020 at 12:25 PM Dotzero <> wrote:

> I am not against experiments, but having reread the entire thread starting
> from Dave's post in August, I believe his concerns are valid.

I want to say again that I make no assertion that any of Dave's claims are
invalid.  The main thing I want us to discuss is whether any of them rise
to the level of halting PSD's movement through the process versus finding a
way to do all of it in parallel, accepting the risks being identified.
Fixing everything first will be extremely time-consuming, but it is a
possible course of action.

My question to the chairs and the group as a whole is whether an experiment
> can be constructed that is valid and useful without "comingling" PSD issues
> and concerns with the core of DMARC at scale? That is, the group that is
> seriously interested does their experiment amongst themselves to produce
> data that supports and justifies such changes in the wild.

Yes, that is the question.  And the working group can still legitimately
conclude that it wants to advance this document before conducting that
experiment.  As you said, rough consensus.

I would remind everyone, however, that this document still needs to pass a
two week IETF-wide Last Call, appropriate directorate reviews, and IESG
review before it can be sent to the RFC editor queue, where again it will
wait for a while.  Assuming we have consensus to proceed in spite of what
Dave and now Mike are saying, we're still at least a month or two from
publication.  That seems a long time to wait before starting the experiment
and collecting data.  Are we sure we want to serialize everything this way?