[dmarc-ietf] How does PSD for DMARC affect tree walk issue?

Doug Foster <fosterd@bayviewphysicians.com> Thu, 19 November 2020 22:15 UTC

Return-Path: <btv1==59250453f96==fosterd@bayviewphysicians.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 D95C53A12DB for <dmarc@ietfa.amsl.com>; Thu, 19 Nov 2020 14:15:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bayviewphysicians.com
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 ZLeRAvJjAaK7 for <dmarc@ietfa.amsl.com>; Thu, 19 Nov 2020 14:15:53 -0800 (PST)
Received: from mail.bayviewphysicians.com (mail.bayviewphysicians.com [216.54.111.133]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 942893A16B1 for <dmarc@ietf.org>; Thu, 19 Nov 2020 14:14:55 -0800 (PST)
X-ASG-Debug-ID: 1605824093-11fa313c01105a0001-K2EkT1
Received: from webmail.bayviewphysicians.com (webmail.bayviewphysicians.com [192.168.1.49]) by mail.bayviewphysicians.com with ESMTP id 1hFkxxRTEXPQvu0Z (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO) for <dmarc@ietf.org>; Thu, 19 Nov 2020 17:14:54 -0500 (EST)
X-Barracuda-Envelope-From: fosterd@bayviewphysicians.com
X-Barracuda-RBL-Trusted-Forwarder: 192.168.1.49
X-SmarterMail-Authenticated-As: fosterd@bayviewphysicians.com
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bayviewphysicians.com; s=s1025; h=message-id:subject:to:from; bh=dJk9p0oFB58aMoJ4xHA1+ZXqgnUmCtHDoduXr2D33xw=; b=oVErTSPPeC9CO6fxu/MmwIu34fKcM2VF6z6oLEb/P2zL4upo1jQ/+ZIWYVvASknkP PDU7R9RioA5L1kHjl2dX+7o0lbOcOgBrXQA3jFlmh2V9+Bjzr+HLXnmWCncqJgCDW eB9Bd+ptwEgcgirO2uA2ED2q6BYbodn5AKcxs3g5A=
Received: from MSA189 (UnknownHost [192.168.2.194]) by webmail.bayviewphysicians.com with SMTP (version=TLS\Tls12 cipher=Aes256 bits=256); Thu, 19 Nov 2020 17:14:46 -0500
From: Doug Foster <fosterd@bayviewphysicians.com>
X-Barracuda-RBL-IP: 192.168.2.194
To: 'IETF DMARC WG' <dmarc@ietf.org>
Date: Thu, 19 Nov 2020 17:14:47 -0500
X-ASG-Orig-Subj: How does PSD for DMARC affect tree walk issue?
Message-ID: <004001d6bec1$6434b630$2c9e2290$@bayviewphysicians.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0041_01D6BE97.7B5EFC50"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: Ada+wJ8JEdWRIYCGSgGnxkHfsy/YOA==
Content-Language: en-us
X-Exim-Id: 004001d6bec1$6434b630$2c9e2290$
X-Barracuda-Connect: webmail.bayviewphysicians.com[192.168.1.49]
X-Barracuda-Start-Time: 1605824093
X-Barracuda-Encrypted: ECDHE-RSA-AES256-SHA384
X-Barracuda-URL: https://mail.bayviewphysicians.com:443/cgi-mod/mark.cgi
X-Virus-Scanned: by bsmtpd at bayviewphysicians.com
X-Barracuda-Scan-Msg-Size: 2623
X-Barracuda-BRTS-Status: 1
X-Barracuda-Spam-Score: 0.00
X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=HTML_MESSAGE
X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.85989 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/eX4S5c2TFZOw_-eoH_C7gYFVZjY>
Subject: [dmarc-ietf] How does PSD for DMARC affect tree walk issue?
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: Thu, 19 Nov 2020 22:15:55 -0000

PSD for DMARC specifies moving up one additional layer of the DNS tree to
look for the PSD policy, but it has the effect of adding DMARC policies to
all levels of participating public suffixes.    How do we judge whether this
workload will be acceptable or not if widely implemented?

 

I ask because it seems to be moving us closer to the performance
implications of a scope-limited tree walk.

 

Doug Foster