Re: [dmarc-ietf] Rethinking DMARC for PSDs

"Murray S. Kucherawy" <> Tue, 09 April 2019 02:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A4B3E12013C for <>; Mon, 8 Apr 2019 19:27:14 -0700 (PDT)
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 adN8nKuQm6GL for <>; Mon, 8 Apr 2019 19:27:13 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9528E120077 for <>; Mon, 8 Apr 2019 19:27:12 -0700 (PDT)
Received: by with SMTP id y6so13005278ljd.12 for <>; Mon, 08 Apr 2019 19:27:12 -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=+bTZNcZJImkgygSCTcye0VcQzpX1q06LtrDR3bjsBwo=; b=iq4iHvOfDSyNLvkZFs2cBe2l66M/25x+T2W4vKnZbnqUwS583U6RxUraYv54+b7UBj Dnh72jbr5K5yBZPeDILUyhox9oOFeNSg4yAd83eA0rwtPi4MuI2cvKbsnn2lATXluY4I dM2jBZZ1qkHAFvdhaN5OQGhffwByrM+NqwrEJ9VQYJdoXusvWsT/2XKUAOd/E25mRzYD PlfgRFiaB9SB1EVXdy9iQBOvcyBkzXhUUHSLHZ0Zr5rXOCf/qa/CVF2HzXCyVfsa7RM4 lzCiQIxGWPG0Y+faygtDa+1buhAK+LTTMRHbaooF8giH9JR+8bExPbPEEJBmxrUTVB7Y jKBA==
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=+bTZNcZJImkgygSCTcye0VcQzpX1q06LtrDR3bjsBwo=; b=ltrK1fXlu2X/a4lvY1sqq6v9lZh4HWOvYmR0+F2OiqZ6L0e5ygehvKx277QtWh5LZt yfQdAL/58HWUkEUjvZ0wEdfSlx223XV2OPdc6k3hO9O39QNilZh9bepmEmHKgZpyxA/l dSUlEEd5M7Xs0B8MtPy6hR28tgPQiA2thds446aM2ZE8tyC3jWKjLpuvEBohGdlFPMUw KN+YoN5PTRoYCCzMLevtTSBHjI0q53/q1yLFEeIlOGHsjmHhqvk86bjk59hSYxO369F+ CUDuc+jmNtnSD7mcZsI75GwGpb03KfcSHXv4dBryo+QntCjHMCGZY1zOYtGJprhOWBrb j7fw==
X-Gm-Message-State: APjAAAVTgRZQ/z/w8jp6g5eR+UzGs3WaFAlRgjayyRu9uUvX9nxIqtYU RowR1F1hIwPgMeh0fKKyGbEg8Pbwn2DRBaqHUAJpvw==
X-Google-Smtp-Source: APXvYqz/VgOq6Y/IN3zKFxZcsStrVmgXp1WVm3xeKkZH/kIidILROgwkTAFr7HJ7ULd49CE828/ImjkQa3wPmL2w3y4=
X-Received: by 2002:a2e:8e96:: with SMTP id z22mr17673084ljk.123.1554776830670; Mon, 08 Apr 2019 19:27:10 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <>
In-Reply-To: <>
From: "Murray S. Kucherawy" <>
Date: Mon, 8 Apr 2019 19:26:56 -0700
Message-ID: <>
Cc: IETF DMARC WG <>, Scott Kitterman <>
Content-Type: multipart/alternative; boundary="000000000000b27b8005860fb0fa"
Archived-At: <>
Subject: Re: [dmarc-ietf] Rethinking DMARC for PSDs
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, 09 Apr 2019 02:27:15 -0000

<chair hat on>

On Mon, Apr 8, 2019 at 5:27 PM Douglas E. Foster <> wrote:

> Scott, you misunderstand what this type of standard would look like.   It
> would defines Use Cases that the device should address, with some
> acknowledgement to the tradeoffs between perceived risk and perceived
> difficulty of implementation.

If what you're looking to do is drum up interest for working on this and,
if there's critical mass to do the work, getting something published, I
suggest any of the following: (message format discussions) (SMTP discussions) (ART area general discussions) (once you have an actual proposal for work that needs a

...possibly others, but those spring immediately to mind.  However, I
believe Scott is correct that this work is not currently within our
charter, and thus it's off-topic for this list.  I don't believe there's
any working group currently chartered to produce something like what's
being proposed here; EXTRA probably comes closest, and I think it's
off-topic there too.

Some years ago Dave Crocker and I assembled RFC 6647 about greylisting,
which was an applicability statement over email in general that talked
about how to implement greylisting.  You could follow that model if you
like, which merits standards track publication, though that means you'll
need to convince an AD to sponsor it or form a working group to develop it.

If my co-chair concurs, then it's appropriate that this conversation be
moved elsewhere.