Re: [dmarc-ietf] third party authorization, not, was non-mailing list

Alessandro Vesely <vesely@tana.it> Wed, 19 August 2020 08:34 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 505D03A11DE for <dmarc@ietfa.amsl.com>; Wed, 19 Aug 2020 01:34:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.047
X-Spam-Level:
X-Spam-Status: No, score=-3.047 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.949, 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 Sy8iiT9pz8kN for <dmarc@ietfa.amsl.com>; Wed, 19 Aug 2020 01:34:02 -0700 (PDT)
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 0AF033A11DD for <dmarc@ietf.org>; Wed, 19 Aug 2020 01:34:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1597826037; bh=t9e5qAcEsWpae97NQBRX4VxzalYOSm8+LIhJLIDIdX8=; l=1228; h=To:References:From:Date:In-Reply-To; b=BgJcLu/vzbFqNCB6lEyE4OcARQ9kitBtYeCJKWhwbftmGXBie1hQGqoOJOm3xsQmA dG/4zuB0oruXB7ZjQHDbvf3C3Hiqb50BRofZku5lJnzEZqHyR9yuKGXY9X1cnu9tyl gXM9AXr5iDk/p3/Rg7VvEY+NXskfFjH+aJrHLGzoELzdgiscl0yRaNmAoKk/N
Authentication-Results: tana.it; auth=pass (details omitted)
Received: from [192.168.1.102] ([5.170.68.187]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.3, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC08B.000000005F3CE3F4.00003F8F; Wed, 19 Aug 2020 10:33:56 +0200
To: dmarc@ietf.org
References: <20200810172411.A13681E7CD8B@ary.local> <7e9326fc-ae27-d4bd-9f2b-9896da8320f1@dcrocker.net> <CAL0qLwacyBbJscEM_a4-nvugO0HBaSAdPqUPkfYYOOb++cOjQQ@mail.gmail.com> <5F396A77.3000109@isdg.net> <CAL0qLwYaqsU-U8yTcr5_cw0LmEomz8JbqUXuWNJ-bnkN6ceXyA@mail.gmail.com>
From: Alessandro Vesely <vesely@tana.it>
Message-ID: <21110e7f-ea60-66d6-c2fb-65b716a049a9@tana.it>
Date: Wed, 19 Aug 2020 10:33:54 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <CAL0qLwYaqsU-U8yTcr5_cw0LmEomz8JbqUXuWNJ-bnkN6ceXyA@mail.gmail.com>
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/e4QdffJ-d4-GDLwnT2-s3W_l6Dk>
Subject: Re: [dmarc-ietf] third party authorization, not, was non-mailing list
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, 19 Aug 2020 08:34:03 -0000

On Tue 18/Aug/2020 01:21:33 +0200 Murray S. Kucherawy wrote:
> The industry in general, and the IETF in particular, have chosen not 
> to pursue widespread use of any kind of standards-based third party 
> domain signature policy or reputation system.  That's the obvious 
> consensus, and in my opinion the reasons for that fact are sound.


Based (also) on the following quoted paragraphs, I wouldn't call this 
state of affairs a choice or a consensus.  It's just a series of failures.


> Both ATPS (individual submission, experimental, February 2012) and the 
> REPUTE series of documents (working group, standards track, late 2013) 
> saw nearly zero adoption after publication even when free reference 
> implementations were provided.  They differ from basic DKIM in that 
> they require non-trivial upkeep, and that appears to be a step 
> function inhibiting adoption among operators.
> 
> [...]  As I said before, I'm disappointed that things like ATPS and
> REPUTE never got a serious attempt, but that's not because they
> were oppressed or sabotaged. That's just the reality we're in.


We can still try again.  In particular, the non-trivial upkeep seems 
to be a valid diagnosis.


Best
Ale
--