Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd

Alessandro Vesely <vesely@tana.it> Mon, 11 November 2019 17:50 UTC

Return-Path: <vesely@tana.it>
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 74CF7120AF8 for <dmarc@ietfa.amsl.com>; Mon, 11 Nov 2019 09:50:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level:
X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1152-bit key) header.d=tana.it
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 iq-diobT7qCj for <dmarc@ietfa.amsl.com>; Mon, 11 Nov 2019 09:50:32 -0800 (PST)
Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61E51120A59 for <dmarc@ietf.org>; Mon, 11 Nov 2019 09:50:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1573494630; bh=I8TUJEwp/tODVq0r0WhwgHx/3c4XnIjrBZXoyc7SYMY=; l=1572; h=To:References:From:Date:In-Reply-To; b=BrcimReCZoGez+RbsYLjMDGfI6hHuwi6DYOHEMv3BWNfNrocDlGhzZxJFG495VS/b 2URPRec35Z97lPfwG5T8bGhKvCViMaIDEJgGy/nWMzQhGK29a3yobVD42syWAKDQgz AS7kD0aVk3ZLv64UJFLs4tcj5pXE88sZRLEfKLGGE1oy+M1Lg1jWstC+7O4vN
Authentication-Results: tana.it; auth=pass (details omitted)
Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k) by wmail.tana.it with ESMTPA id 00000000005DC053.000000005DC99F66.0000461E; Mon, 11 Nov 2019 18:50:30 +0100
To: dmarc@ietf.org
References: <728d7df1-d563-82f4-bfb3-a65a75fdd662@gmail.com> <CAL0qLwacbAT04tckpPcRcnOt=1QByOBeJ7uDf6rNK6NRwtxZYg@mail.gmail.com> <ffa2bf72-3024-237b-86ae-9cc04babeec6@gmail.com> <74a0ea49-7a46-4eb6-c297-cd703f63bd1b@gmail.com> <CAL0qLwbp2hNrgF_xxhKRRODQ6HP=U5_K-r3Wtm1wJZOZcKup3g@mail.gmail.com> <9DE9E7DC-FE60-4952-8595-B2D087A6B780@kitterman.com> <CADyWQ+GSP0K=Ci22ouE6AvdqCDGgUAg3jZHBOg3EwCmw=QG84A@mail.gmail.com> <CABuGu1obn55Y2=CuEYRYCEO3TYYNhYTsdkesQ67O61jRyfO=wA@mail.gmail.com>
From: Alessandro Vesely <vesely@tana.it>
Openpgp: preference=signencrypt
Message-ID: <59947cf1-1851-af56-536e-f78530e79dd2@tana.it>
Date: Mon, 11 Nov 2019 18:50:30 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: <CABuGu1obn55Y2=CuEYRYCEO3TYYNhYTsdkesQ67O61jRyfO=wA@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/CoIkpgi4aTv0TyJS4RlLcMy5URc>
Subject: Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd
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: Mon, 11 Nov 2019 17:50:35 -0000

On Mon 11/Nov/2019 16:46:17 +0100 Kurt Andersen (b) wrote:
> 
> I don't think that it is fair to say that anyone who refers to the org domain
> concept as cited in the DMARC spec is necessarily invoking the PSL.


Agreed.  The PSL just happens to be the only valid tool to do that.

For various reasons, large organizations administer many apparently unrelated
domains.  For example, _dmarc.youtube.com has a rua mailto ending in
@google.com.  We cannot infer an OD from that, but I think the concept is clear.


> I do have a problem with the conflation of the org domain with a
> super-organizational "realm" (?) that may impose conditions upon organizations
> that fall within their jurisdictional purview. My main concerns are with the
> potential usurpation of the org domain's policy declaration rights. "Moving"
> the org domain up one level disenfranchises the organizations and that is the
> wrong thing to do IMO.


The I-D definitions are clear enough.  Section 2.5, in particular, prevents the
conflation neatly.


> As to the proposed "let's run this as an experiment pending DMARCbis", I don't
> see how that satisfies Dave's concern about creating new work for receivers in
> order to help a small set of domain (realm) owners. I'm not opposed to it, but
> I just don't see how this solves the issue.


Isn't that an ICANN problem?  For the time being, dig _dmarc.bank txt returns
an empty NOERROR response, while _dmarc.gov.uk returns a valid record.  The
latter is a Nominet, already solved problem, AFAICS.


Best
Ale
--