Re: [dmarc-ietf] Domains

"Murray S. Kucherawy" <> Wed, 02 December 2020 19:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C63F43A1766 for <>; Wed, 2 Dec 2020 11:48:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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 aeEE1KCDd2-I for <>; Wed, 2 Dec 2020 11:48:45 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::92e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8A8573A15DD for <>; Wed, 2 Dec 2020 11:48:14 -0800 (PST)
Received: by with SMTP id y21so588229uag.2 for <>; Wed, 02 Dec 2020 11:48:14 -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=9qt76ysejWl7nq2ZYAbXrYIqZeMzbFwQrh93/6hE1n8=; b=Ue26aYeYxKXQ5O1ENShCeqS4YxvKQZ4zF4PdsgZ2cXcWdA2Sxg1ECu9o2QV7fDnolx JdMHj0XhguUWRy9IgCRy6UcZQVpSK0AGW5a2tlNUyRfkBxdTMoX57LDq/h3mKdO5zoas Kelu6lrg/xfcDBZiciJidFH2Eqsjf20zTdPa6ZwUp3ECLOrygLk+6zCm2/Z8ZULhmEKP NH2UJ0UxgUvjmZvIMQp6v3gcJHTiZwWtEX2DBfGIfDO4PVXTCbfb6KypIM6cvyurqOjj N/R3ggIw4yhA7RODXRlY7ABqoFiHSHE1r3uxuO5sKCIzylHIzMFK2sLNQZYpS/z8t1rj amSQ==
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=9qt76ysejWl7nq2ZYAbXrYIqZeMzbFwQrh93/6hE1n8=; b=EH9b+sS3q1jgu91FFVH0sDwifwB/3I2MDGsIODMzZsUlOgSCEdkAIwo8waLlyBSu62 eSX7xm0S3O1N9kTNGQDojsynH5/m23hjtmkpZ0q+hX/cSaBn4leHCqTbbZHyxCTkphbY NiJipvaqebXeSApctSSOO2qm6xqVgcXHPUZPC4v/weGQIjMmpy+FlKaUiembFbW4z+zm NwlmmAecgjwhdmRV4YT8zS768ZsfIvwItP7VxriBdcDpZu8vqsBppkM/DnzCORmYSVi5 AV+736F11miM31s7SR4d4sO36LFrhxSV6uZcSD2cZRfUVdOqTDbU49SlsW+bKIsXHHFB gkNA==
X-Gm-Message-State: AOAM531X9oBls1XBYQf3FErasw9y2drh9fn9DkOZEhIPHBMQFAgB5DkC pUMLTGHynJcCBe9ohvcQFfk2rt/MUaJBV0mWmOs=
X-Google-Smtp-Source: ABdhPJyllX9Cat9oWFJauu8X6FFPlopdXsQE8QpfWuZANvxIiqTFlsd4lGwehS4rg2z4KEwesUw78qe/qwbAPFq9tCE=
X-Received: by 2002:ab0:2e9:: with SMTP id 96mr2859099uah.87.1606938493461; Wed, 02 Dec 2020 11:48:13 -0800 (PST)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: "Murray S. Kucherawy" <>
Date: Wed, 2 Dec 2020 11:48:02 -0800
Message-ID: <>
To: Joseph Brennan <>
Content-Type: multipart/alternative; boundary="000000000000142b4005b58086bb"
Archived-At: <>
Subject: Re: [dmarc-ietf] Domains
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: Wed, 02 Dec 2020 19:48:54 -0000

On Tue, Dec 1, 2020 at 5:44 PM Joseph Brennan <> wrote:

> I want to ask again why DMARC should consider any domain other than
> the one in the Header From. The purpose of DMARC should be stated
> right at the top of the proposed standard. It is intended to control
> use of a domain in the Header From. If the Header From has
>, the DMARC record for should
> apply.
> It does not make sense to me to say that if the Header From is
>, and there is no
> record, then recipient systems should continue to look for
> and apply the dmarc rule there. I know of no other
> standard that requires this type of relationship. This is something
> new. It will require administrators to continually check what their
> sub- and supra-domains are doing in order to escape interference by
> DMARC records they did not create. I think this is unreasonable. Only
> domains interested in applying DMARC should be involved with DMARC.
> Others should be able to do what they want. I know that otherwise will
> out rule out DMARC for the "" domain that I administer.

If DMARC is thus constrained and you have a "p=reject" on ""
only, then nothing stops me from generating unauthenticated email with a
>From field indicating "" for any subdomain "foobar",
whether or not it actually exists in the DNS.