Re: [dmarc-ietf] PSD simplification

"John Levine" <johnl@taugh.com> Wed, 12 December 2018 16:59 UTC

Return-Path: <johnl@iecc.com>
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6820126DBF for <dmarc@ietfa.amsl.com>; Wed, 12 Dec 2018 08:59:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
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, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=pU1QsZDo; dkim=pass (1536-bit key) header.d=taugh.com header.b=0SG1y1tk
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zq3a8_1oxgR8 for <dmarc@ietfa.amsl.com>; Wed, 12 Dec 2018 08:59:16 -0800 (PST)
Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F18C130EE7 for <dmarc@ietf.org>; Wed, 12 Dec 2018 08:59:16 -0800 (PST)
Received: (qmail 41506 invoked from network); 12 Dec 2018 16:59:14 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=a220.5c113e62.k1812; bh=ugLaXtInsDJqdcMwWUy2lbL0SRiWBHVivAPK3BBz+iw=; b=pU1QsZDoA4HsfP8EJeeTVi6XD2WPaPq7xuVJhHntSixBkuLBr1rT9I1fFWiaxU+FK2DAiNnPoxfkTP7nHRK/yAm+fPbyjPWekX6liOBgEY/JC70RAlI7DPxhRs9jQe+G6PLH4P7Uu79wYOSu8vvwFqdzBCDBtIuQlW9+YQNg+1Zij1nluIgSRhonye6w6h3phBdl2e0WQkElboNx6wYsVNU4JYGjGYPa2LkziwOvKxr2bqi8u7iybfiWhtZFhKey
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=a220.5c113e62.k1812; bh=ugLaXtInsDJqdcMwWUy2lbL0SRiWBHVivAPK3BBz+iw=; b=0SG1y1tk5lQXppOkpp6E9sX+SZza5jdD59JSO3L/9zYPyohPpFLf5qnTUVIZDdop5AvNQfWXkiMASBXAprXQtM8IwR+7aIe7+HqLCLecPNMvzLVfljTbIMwA31+SKAXEpeHS7oJFIKALd/caTefSWrDt7VLZkT+6iXcbG3dDnDM79Z7z/ufEROhl3NCTK9VQrcSfO5TMrjcf1/YqxpM1x2VV6WuNanuDSeyieyct5pn1zCTp1CUFeAE1Zw3kqzW5
Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 12 Dec 2018 16:59:14 -0000
Received: by ary.qy (Postfix, from userid 501) id 36A76200B6363D; Wed, 12 Dec 2018 11:59:13 -0500 (EST)
Date: 12 Dec 2018 11:59:13 -0500
Message-Id: <20181212165914.36A76200B6363D@ary.qy>
From: "John Levine" <johnl@taugh.com>
To: dmarc@ietf.org
Cc: dcrocker@bbiw.net
In-Reply-To: <1b0bef4b-61e6-776c-79e8-89631efa8053@dcrocker.net>
Organization: Taughannock Networks
X-Headerized: yes
Mime-Version: 1.0
Content-type: text/plain; charset=utf-8
Content-transfer-encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/q871448cLZqh5yMiJv8VlW2N_BM>
Subject: Re: [dmarc-ietf] PSD simplification
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" <dmarc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmarc>, <mailto:dmarc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dmarc/>
List-Post: <mailto:dmarc@ietf.org>
List-Help: <mailto:dmarc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmarc>, <mailto:dmarc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 12 Dec 2018 16:59:19 -0000

In article <1b0bef4b-61e6-776c-79e8-89631efa8053@dcrocker.net> you write:
>So I think that the functional goal of kitterman-dmarc-psd is fully 
>satisfied by merely doing a version of the 3A update to DMARC, directing 
>the client to query the immediate parent of the organizational domain, 
>if the OD has been queried and no DMARC record has been found.

Given that anything we do to handle public suffix defaults will need
some code changes, this seems about the simplest change that would do
the trick.

I am aware of two security or privacy issues that might come up.  If
we used a DNS scheme like my DBOUND one, whoever runs the DNS policy
server can see all the queries and will have some idea of the mail
traffic from various names.  This approach doesn't have that problem.
The DNS operator can tell that someone is asking about a subdomain,
but not which subdomain.

The other is that the DMARC record might have rua= and ruf= and get
detailed reports about subdomains.  This is not an unreasonable concern --
I am the legacy registrar for various <geographic>.ny.us domains and
my DMARC reports tell me a lot about one of my registrants who sends
a lot of mail.  (Real mail, they're the county govermnent.)  This is
easily addressed by clients ignoring the report advice in the OD
parent record.

One issue that is not our problem but might be Scott's is that in
ICANN contracted TLDs, they're not allowed to publish TXT records at
_dmarc.BANK or _dmarc.INSURANCE unless they apply to get special
permission to do so.  I happen to know the people who evaluate the
applications (as do many other people here) and I'm sure they would
say yes for those two TLDs, but it would involve some time and money.
This might actually be a feature, since a similar appplication for
_dmarc.XYZ or _dmarc.SUCKS would be treated with a lot more
scepticism.

R's,
John