IETF Logo Mail Archive

Re: [dmarc-ietf] Organizational domains, threat or menace, was On splitting documents and DBOUND

Alessandro Vesely <vesely@tana.it> Fri, 13 November 2020 12:25 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 875363A0799 for <dmarc@ietfa.amsl.com>; Fri, 13 Nov 2020 04:25:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 e2iXK1l7B0I0 for <dmarc@ietfa.amsl.com>; Fri, 13 Nov 2020 04:25:03 -0800 (PST)
Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (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 2E5FE3A0121 for <dmarc@ietf.org>; Fri, 13 Nov 2020 04:25:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1605270299; bh=cvV07DveXf7DSlRcLpu5GeF6gAI/1a0A7hzVnouKIhs=; l=1035; h=To:References:From:Date:In-Reply-To; b=Ch5sqAq+lz3JqLTRNEdqH4IFXo8Y9+GtCPDrCApznsAwqwqAxYZ2PCNj17CTsJCqC Bh2FWAoDwkCKUvRs9y+1YNRvHOEMMbBPkC3NYjiXLy7CWkvl+X19RX9REDN3xXw42A Cp8J4gSARHOgBSxyQf4WcFlrBi/FC/p+GPO55YDR+D3KYRdlfh/9jdhReEEdd
Authentication-Results: tana.it; auth=pass (details omitted)
Original-From: Alessandro Vesely <vesely@tana.it>
Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.3, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC083.000000005FAE7B1B.000040EE; Fri, 13 Nov 2020 13:24:59 +0100
To: dmarc@ietf.org
References: <20201112212323.1023C2639B17@ary.qy> <85b5b3ac-1072-3f8f-b473-e688f5885dd5@dcrocker.net>
From: Alessandro Vesely <vesely@tana.it>
Message-ID: <dde7fac0-4fc0-8022-7f3b-552e4ae22da1@tana.it>
Date: Fri, 13 Nov 2020 13:24:58 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0
MIME-Version: 1.0
In-Reply-To: <85b5b3ac-1072-3f8f-b473-e688f5885dd5@dcrocker.net>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/p9XJOd5xPBeuNQFnsbNfKOQmKkc>
Subject: Re: [dmarc-ietf] Organizational domains, threat or menace, was On splitting documents and DBOUND
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: Fri, 13 Nov 2020 12:25:05 -0000

On Thu 12/Nov/2020 22:31:25 +0100 Dave Crocker wrote:
> On 11/12/2020 1:23 PM, John Levine wrote:
>> The semantics are definitely not the same. You now can put a DMARC
>> record on a name below the org domain to shadow a subtree,
> 
> 
> that's why the group should first focus on the semantics it wants/doesn't want, 
> independent of how the semantics are achieved.  The statement of what is wanted 
> should be administrative/authority language, not technical language.


Agreed.  And I don't think that a tree walk would match DMARC semantics.

AIUI, the Organizational Domain must be a domain recognized by all "subdomains" 
as authoritative on policies.

Of course, if every organization had the ability to generate DNS records for 
each domain, there would've been no need to use the PSL.  SPF experience taught 
that even "smart" organizations may lack the ability to do so.  Hence, the 
Organizational Domain must be such that its admins are entitled to generate 
those records if they wanted to.


Best
Ale
--

v2.23.0 | Report a Bug | By Email