IETF Logo Mail Archive

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

"Douglas E. Foster" <fosterd@bayviewphysicians.com> Mon, 24 August 2020 22:34 UTC

Return-Path: <btv1==5058aa428ec==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 2BEFB3A0E22 for <dmarc@ietfa.amsl.com>; Mon, 24 Aug 2020 15:34:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.198
X-Spam-Level:
X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[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 sW7oKcb0EWXI for <dmarc@ietfa.amsl.com>; Mon, 24 Aug 2020 15:34:39 -0700 (PDT)
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 BF59E3A0E30 for <dmarc@ietf.org>; Mon, 24 Aug 2020 15:34:39 -0700 (PDT)
X-ASG-Debug-ID: 1598308477-11fa31095ea4b00001-K2EkT1
Received: from webmail.bayviewphysicians.com (webmail.bayviewphysicians.com [192.168.1.49]) by mail.bayviewphysicians.com with ESMTP id L7NHO9gnn0YVri7s (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO) for <dmarc@ietf.org>; Mon, 24 Aug 2020 18:34:38 -0400 (EDT)
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:reply-to:subject:to:from; bh=aucNvN25dqYTYsmH6BnGO2WVjaPCHCDDwL89HQqiFsM=; b=Fzgb3DRNlNnCCcBsOEmW+NA9vDSVJ3ja/EJWUONweAvC9SyrM8RY+6Wmk6k2pVUlH TPa7x14HuImvP2h5NsLMd9V9+L5ThmE/dNxeLWyWmqbokjqoggf+3GGfrfcKlT+lH v+JDLgS7l8Wy7WBsYGDur6lT9o0Gf/3b/vCacAlBs=
From: "Douglas E. Foster" <fosterd@bayviewphysicians.com>
To: "dmarc@ietf.org" <dmarc@ietf.org>
Date: Mon, 24 Aug 2020 22:34:31 +0000
X-ASG-Orig-Subj: Re: [dmarc-ietf] third party authorization, not, was non-mailing list
Reply-To: fosterd@bayviewphysicians.com
Message-ID: <5e1469f9af1347569cac199ea9318d54@bayviewphysicians.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="853c4097e2ab49d7a908b8af9b8142c8"
In-Reply-To: <CAL0qLwY_zgLrQo=25kMi=3Qe4b_=BNY_u4qz4V13UwKrL8x-KQ@mail.gmail.com>
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> <21110e7f-ea60-66d6-c2fb-65b716a049a9@tana.it> <CABuGu1qdZdXBSsAwCvk4244szskz6Pf9x83kRUGd8jHDafEMGQ@mail.gmail.com> <CAL0qLwYY8ZWq4k3wobOgSJSVnabsefPRiCtcVPrb_iF1JEUZag@mail.gmail.com> <5d4e48f86ca7479ab4889ddff57a2870@bayviewphysicians.com> <6c7c2ad9-8a7e-e44c-6b2f-559129f70a9d@tana.it> <CAL0qLwb-SG-dsNkiiGtYkUz_AwsZSd6f5cKFX07Kzme5iXoZJA@mail.gmail.com> <F37D57E3-C55B-41EB-B4BE-328E40F73E81@eudaemon.net> <CABa8R6sUoyaa8sMJVOCnUUuH=g--2PSNQ-eLhVuW5NorzcQvqA@mail.gmail.com> <CAL0qLwY_zgLrQo=25kMi=3Qe4b_=BNY_u4qz4V13UwKrL8x-KQ@mail.gmail.com>
X-Exim-Id: 5e1469f9af1347569cac199ea9318d54
X-Barracuda-Connect: webmail.bayviewphysicians.com[192.168.1.49]
X-Barracuda-Start-Time: 1598308478
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: 4286
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.84138 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/3513cPi36H8cGN-Amd4MoePW4Is>
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: Mon, 24 Aug 2020 22:34:41 -0000

Something seems inconsistent:

- The people who have implemented DMARC do not see any significant problems, and as a result they are not interested in a third-party authorization scheme.

- Yet adoption is very slow, especially for anything other than p=none

Are we to assume that mailing list compatibility explains the slow adoption?   If not, what other obstacles do we need to be considering?

DF

----------------------------------------
From: "Murray S. Kucherawy" <superuser@gmail.com>
Sent: 8/24/20 11:21 AM
To: Brandon Long <blong@google.com>
Cc: IETF DMARC WG <dmarc@ietf.org>, Tim Draegen <tim@eudaemon.net>, Alessandro Vesely <vesely@tana.it>
Subject: Re: [dmarc-ietf] third party authorization, not, was non-mailing list
On Thu, Aug 20, 2020 at 2:01 PM Brandon Long <blong@google.com> wrote:
I tend to agree with the negative stance on third party auth, but SPF obviously has the include: statement which is third party auth at the most basic level...atps[1] is the obvious equivalent for DKIM.  I don't know if atps failed because it wasn't all that useful, or if it was tied in folks minds to adps, or the failure of the follow-on reputation system stuff..

Neither atps or spf include are really designed for large scale usage across thousands of "relays" etc, and I don't think they should be used for that, but for a bunch of small to medium entities, it could be the thing that makes higher p= possible.

ATPS was designed as a proof of concept to see if third party policy was conceptually useful at all.  Scale could come later if the initial experiment had a positive result.  The industry, however, apparently didn't even have appetite to try, so we may never know.

-MSK

v2.23.0 | Report a Bug | By Email