Re: [dmarc-ietf] Summary comments on draft-ietf-dmarc-psd

"Murray S. Kucherawy" <> Wed, 18 March 2020 23:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A2C8F3A0986 for <>; Wed, 18 Mar 2020 16:29:55 -0700 (PDT)
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 VTJgpMGm3elC for <>; Wed, 18 Mar 2020 16:29:53 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::a36]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A8C583A098A for <>; Wed, 18 Mar 2020 16:29:53 -0700 (PDT)
Received: by with SMTP id s194so187054vkb.11 for <>; Wed, 18 Mar 2020 16:29: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=zNp70waff63RgfyxN17JtLRgP8++AfDMnjtCc+HxDp8=; b=MQscjxODIrn+58O0hu+9WTL+zU+RKy+uxMqYUf4+FFWC3uX02aqxkarDcIk6sZacQM wxDVpwXGK7vwToY1wGqrXrO2mh2ENazTaNfWeSwrdX5T2ylL8vdtIJ3EVnp4Rfyxc9Zg qWCjNN5hA/4k1y4wZPw1hlpH5pzcwJSv5eIW8IMN/ChIrBK3yHP2mFlrc5ReXvWramdw 8ourzLymZ6132+/N7YXpgLnt6JdRMusjd72Jzk0ehGUKiMi91Pb7H2GnNNxuyXQ+9TF3 qr2UUE6g3XJSp5Ffrc9w8gCmNcSrHXA1dGb8Z0tQnB9JqIrr5ab1HPINY7CVw0JDHLTa l6mg==
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=zNp70waff63RgfyxN17JtLRgP8++AfDMnjtCc+HxDp8=; b=sq28cVMa9wr7Oh49dyvwCB0Up+9dTtBut9HDr7yK9odGo3XKXxwzo9K11g0cIW13iN xQV26uKKevfenWO+AEF5YoS/P4H/HpjIqMMgTZtmpU8AgDSawORd0u+Mgyj4PL7tI9fV OOsSsi/jkmTxwlqRCz13nE1mbf05lBKqaxWfoXUCtYnj6GOrRWyzT7iuAklwHstNDUA4 S2UBGUrMUrjRow33bmwx2jRx/B7hp4L9gijGcsvsT2lBir64zN89q4eSlyBlp6dela2g Ty/RbRdQgxcxV6zK7XrwCtb8EJj3uw3AmFAn4LRpj6rh1pUaLQhFYYVlt3w2kKKCTYo6 zuMw==
X-Gm-Message-State: ANhLgQ25dapJv/mfNAOZHOSpK8vAd84de8VrBBZ9lzvihrJ+EdQSNMoK qLGVcwlP5gRzoGycbZrfp7fP427WC92pk/Nh+M4XrnxK
X-Google-Smtp-Source: =?utf-8?q?ADFU+vvEQDOuSjbi2fx5+O9c+0WGonVUzLmNotYgnTA3?= =?utf-8?q?X9wMnE9gCdPa1griGKz9/hz7Cg6xNk1Z8i5qvfQUrwRBgAY=3D?=
X-Received: by 2002:a1f:188f:: with SMTP id 137mr550337vky.95.1584574192625; Wed, 18 Mar 2020 16:29:52 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
From: "Murray S. Kucherawy" <>
Date: Wed, 18 Mar 2020 16:29:41 -0700
Message-ID: <>
To: Dave Crocker <>
Content-Type: multipart/alternative; boundary="000000000000df2c8005a1296d9e"
Archived-At: <>
Subject: Re: [dmarc-ietf] Summary comments 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: Wed, 18 Mar 2020 23:29:56 -0000

On Sun, Mar 15, 2020 at 5:49 AM Dave Crocker <> wrote:

> On 3/11/2020 8:36 PM, Murray S. Kucherawy wrote:
> Since we're mentioning a tree walk here, I believe we are ripe for a
> reopening of that debate.
> That's a shame. Besides created additional general cost, it creates an
> attack vector.
> Consider: From
Yeah, I'm familiar with the nature of the attack.   But based on what
amounts to the hallway track, it feels like the perspective of the DNS
community these days is that the currently deployed DNS infrastructure
could easily deal with such an attack, to at least the extent that it's not
a blocker for something potentially useful like resolving the
Organizational Domain problem for DMARC.

Tim might be able to elucidate here.

I believe where this is leading, though, is toward the notion that the use
> of the PSL should be considered external to DMARC.  I don't think anyone
> has disagreed with that assertion.
> And yet both DMARC and PSD have text tied to the term and its function.
My point here is that I believe we've already agreed that you're correct,
and this separation should happen, but there's no apparent urgency that
MUST be done before the PSD experiment can proceed.  Indeed, I'm fairly
certain the amount of code change in my own implementation in order to be
compliant with such a change in the specification is around zero.  The
audience for the experiment, by my read, also agrees, so they understand
the need, but this won't change the experiment either.

> > 2. Externalizing internal difficulties
>> >
>> > Some organizations have sub-groups to which various administrative
>> > responsibilities have been delegated.  In general, there can be many
>> > levels of such delegation.  Not just two.
>> >
>> > For the cases the PSD specification is intended to cover,
>> > PSD seeks to adapt to slow DMARC adoption or non-existent domains for
>> > one of its delegated sub-groups, by looking for an even-higher-level
>> > encompassing record under a next-level Organizational Domain.  That is,
>> > PSD is specifying using two different Organizational Domains.  The usual
>> > one and its parent.
>> >
>> > A difficulty within the organization is being externalized to a burden
>> > for everyone else on the net.
> Can you expand on how you see abuse of non-existent domains to be an
> exploitation of an internal problem?  Specifically, what's the internal
> problem being exploited?
> I apologize for not being more clear about what I meant.  I hope that the
> above effort elaborate on this suffices.  Basically it concerns an
> organization's inability to get its subordinates to publish DMARC records
> and problems with PSLs that lead to identifying the wrong domain as an OD.
> Or somesuch...
The issue PSD is attempting to address is mail sent as a nonexistent
subdomain.  For example, doesn't have a subdomain called, so irrespective of any DMARC policy, I could send
email as without limitation.  The goal here is to come
up with a mechanism to prevent this.  Obviously the maintainers of
can't anticipate all possible nonexistent names that might be used, so
either something like PSD is needed, or some kind of wildcarding mechanism
is needed by which the domain owner can block any name they're not actually
using.  What such mechanism could be developed?  Don't wildcard TXT
records, for example, have some other side effects?