Re: [dmarc-ietf] Bridging the gap

Scott Kitterman <sklist@kitterman.com> Sat, 18 June 2022 13:18 UTC

Return-Path: <sklist@kitterman.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 E52DAC15D86F for <dmarc@ietfa.amsl.com>; Sat, 18 Jun 2022 06:18:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.109
X-Spam-Level:
X-Spam-Status: No, score=-2.109 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, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=kitterman.com header.b=KpDIZMGM; dkim=pass (2048-bit key) header.d=kitterman.com header.b=j9rtRsVC
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hnq-0w56h959 for <dmarc@ietfa.amsl.com>; Sat, 18 Jun 2022 06:17:59 -0700 (PDT)
Received: from interserver.kitterman.com (interserver.kitterman.com [64.20.48.66]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E409C15D86E for <dmarc@ietf.org>; Sat, 18 Jun 2022 06:17:59 -0700 (PDT)
Received: from interserver.kitterman.com (interserver.kitterman.com [IPv6:2604:a00:6:1039:225:90ff:feaa:b169]) by interserver.kitterman.com (Postfix) with ESMTPS id E6712F802DB for <dmarc@ietf.org>; Sat, 18 Jun 2022 09:17:57 -0400 (EDT)
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1655558277; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=Fa+QL0nKZxIHAA5eUlRoybdbALVMEP8SfyDSvxJO91Q=; b=KpDIZMGMbxQPvDqthid6ILnyTD7SlRccExtol9VQSGpX0E0i3vpXacggKfPoifWVOeo9J Fd5go4Rx3PyYlZ3AA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1655558277; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=Fa+QL0nKZxIHAA5eUlRoybdbALVMEP8SfyDSvxJO91Q=; b=j9rtRsVC3jgwe3HGNeLXNGSW5es/Nzjl1F9SNynk4AWS/uuTUJes/VTP2RHiDv2B4rgMQ BUtp5GGeAW0Ixoc4csY3Nl+hRUZ4KWh262LjxfRdDX71ged7jNcqwBZE2hfw7snd+3lARo8 3Kr8M93EyY5Jv++iWssn9xcfONWB/7+3gB6GPeVdLvEe9UDv/2RR3gXQqCiaVstl0bckCke DxSPX3kpwdlTBfIWMPWIlscAF3oa8RyJSCNhi6IQ7ywK6qoC05XDo/zE0dfpRm38xB1mpQN w4bRSwRXILTCqiIdgE3JF85a0EbC/RMY8lREDKaNRAzcKz5XMEGQQ/LzUBcg==
Received: from zini-1880.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) by interserver.kitterman.com (Postfix) with ESMTP id B6CBEF8020E for <dmarc@ietf.org>; Sat, 18 Jun 2022 09:17:57 -0400 (EDT)
From: Scott Kitterman <sklist@kitterman.com>
To: dmarc@ietf.org
Date: Sat, 18 Jun 2022 09:17:57 -0400
Message-ID: <2140913.zk14TfHaxj@zini-1880>
In-Reply-To: <1a6f4fc8-6567-917f-8365-6fcee7b28348@tana.it>
References: <20220615174742.BBCE443B1333@ary.local> <2556752.voWYGx1xz9@zini-1880> <1a6f4fc8-6567-917f-8365-6fcee7b28348@tana.it>
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/i0mFNmBJTbISw0T8Bte-s4ch0DM>
Subject: Re: [dmarc-ietf] Bridging the gap
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.39
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: Sat, 18 Jun 2022 13:18:05 -0000

On Saturday, June 18, 2022 7:25:28 AM EDT Alessandro Vesely wrote:
> On Sat 18/Jun/2022 02:40:49 +0200 Scott Kitterman wrote:
> > On Thursday, June 16, 2022 11:57:08 AM EDT Alessandro Vesely wrote:
> >> On Wed 15/Jun/2022 19:47:42 +0200 John Levine wrote:
> >>> It appears that Alessandro Vesely  <vesely@tana.it> said:
> >>>> I think we found the few critical domains which need a flag.
> >>> 
> >>> We may have found some domains that need a psd flag, but it's silly to
> >>> assert we have found all or even most of them.
> >>> 
> >>> The PSL has 9300 entries and there are surely far more places in the DNS
> >>> than that where you want sibling domains to be separate.
> >> 
> >> Is there someone who is going to contact, on behalf of the WG, the
> >> domains
> >> that were found in order to have their owners publish psd= flags before
> >> the
> >> RFC is published?
> > 
> > It is a project I intend to work on once the psd= tag has been assigned.
> > Until the working group has settled on it more definitively than "it's in
> > the current draft" I think it would be premature to bother them.
> 
> Agreed, we can wait until RFC queue.

I don't think we need to wait that long.  I have heard the designated expert 
for the registry is open to early registration if the chairs determine there 
is rough consensus for psd=.

> I think many of the required tasks can be discussed here.  Namely:
> 
>   * Listing relevant domains,
>   * finding contacts for listed domains,
>   * composing the text of an email to send them.
> 
> Actually sending those messages would sound more credible if done From:
> Someone@IETF.org.  Does such a role exist?

I don't think so.  In my experience it's external groups that are interested 
in a new technology that deal with evangelizing it once developed by the IETF.  
Since RFCs don't write themselves, there's generally someone.

> > From your list further down the thread, why do you think having a psd=y
> > tag on gov.uk, police.uk, and mil will have?  While it would be more
> > descriptively correct, I don't think there's any operational difference
> > if it's there or not since sub-domains of those PSDs are controlled by
> > one organization.
> I don't know how much control do parent domains exercise downwards.  It
> probably varies widely in each case.  Anyway, the tree walk needs those
> flags in order to work properly.
> 
> > If us.com had a DMARC record, that would be worth a discussion, but they
> > don't.
> 
> Why does uk.com differ?  They do have a DMARC record.

I have no idea why they are different, but that's the best example I've seen so 
far of a record for which psd=y would be important.  Once the tag is assigned, 
someone should definitely discuss this with CentralNic.  If no one on the list 
knows someone there, my guess is that it's almost a certainty that someone on 
the list knows someone who does.

> > It's not even the ~500 domains on the PSL that have DMARC records
> > published
> > that we need to concern ourselves with, it's a small subset of them.
> 
> I counted 238 of them, discarding the ones with '*'s.  Many can be grouped,
> for example blogspots and all Google stuff.  The PSL refers contacts in
> comments.
> 
> I don't know how to better select the domains which need to set the flag.
> Presumably, the mail will say something such that each domain owner can
> understand which domains are involved.

I'm willing to work on this at the appropriate time and i know others who are 
as well.  I think, for now, we should proceed on the assumption that the 
evangelization of the psd= tag will get done.  It needn't be done overnight as 
it will have no effect until mail receivers implement the associated 
processing.  That will be the bigger lift in my opinion.

Scott K