Re: [dmarc-ietf] Ticket #39 - remove p=quarantine
Hector Santos <hsantos@isdg.net> Tue, 08 December 2020 17:18 UTC
Return-Path: <hsantos@isdg.net>
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 AF5683A1051 for <dmarc@ietfa.amsl.com>; Tue, 8 Dec 2020 09:18:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.101
X-Spam-Level:
X-Spam-Status: No, score=-2.101 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, 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=isdg.net header.b=LUAoZ8Jv; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=0Gd4dUZp
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 eUqRhkMT80VA for <dmarc@ietfa.amsl.com>; Tue, 8 Dec 2020 09:18:26 -0800 (PST)
Received: from mail.winserver.com (secure.winserver.com [76.245.57.69]) (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 B6E9E3A104B for <dmarc@ietf.org>; Tue, 8 Dec 2020 09:18:25 -0800 (PST)
DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha256; c=simple/relaxed; l=7537; t=1607447897; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=unQ/cVDy9FYBRtGqvpawX3Y6uVLn RxhTb9vqDMKWi5c=; b=LUAoZ8Jvz1zbq3kKNm0qH1N2Yxixl4WiL1g8U+LKGd/r hzzf8xPJuhT0aDqvwltx8+4OBLCBBrL6PqubP+aWKOS0IK344SOKWGqtC+AxB0i9 gp05Z6VIbBwoJcNiNY/D4MKdVT1isr7OVEI41mdgIwuanqmBRlUp4Akdx0BKdyc=
Received: by mail.winserver.com (Wildcat! SMTP Router v8.0.454.10) for dmarc@ietf.org; Tue, 08 Dec 2020 12:18:17 -0500
Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; dmarc=pass policy=reject author.d=isdg.net signer.d=beta.winserver.com (atps signer);
Received: from beta.winserver.com ([76.245.57.74]) by mail.winserver.com (Wildcat! SMTP v8.0.454.10) with ESMTP id 887981359.1.4088; Tue, 08 Dec 2020 12:18:15 -0500
DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=7537; t=1607447557; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=unQ/cVD y9FYBRtGqvpawX3Y6uVLnRxhTb9vqDMKWi5c=; b=0Gd4dUZp/if0o2dYV7FcHN8 Q9BIKG/3aQ8p9+dYpLuYgQ2CHxnID4Zbew9KCUCiZ/3YdmfDBuEhQJbSGueroNk8 ZwkUlazQwwr9HRIHZKzc/EXI8YuSNpytgVy6nEF7TvmRSc+i9P0fdo0plKxM7YOD u3Pk2ytZeBBcQVSzsyV4=
Received: by beta.winserver.com (Wildcat! SMTP Router v8.0.454.10) for dmarc@ietf.org; Tue, 08 Dec 2020 12:12:37 -0500
Received: from [192.168.1.68] ([75.26.216.248]) by beta.winserver.com (Wildcat! SMTP v8.0.454.10) with ESMTP id 754862236.1.12368; Tue, 08 Dec 2020 12:12:37 -0500
Message-ID: <5FCFB555.2050800@isdg.net>
Date: Tue, 08 Dec 2020 12:18:13 -0500
From: Hector Santos <hsantos@isdg.net>
Reply-To: hsantos@isdg.net
Organization: Santronics Software, Inc.
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1
MIME-Version: 1.0
To: Дилян Палаузов <dilyan.palauzov@aegee.org>, Brandon Long <blong=40google.com@dmarc.ietf.org>, "Murray S. Kucherawy" <superuser@gmail.com>
CC: IETF DMARC WG <dmarc@ietf.org>, Dotzero <dotzero@gmail.com>, Benny Lyne Amorsen <benny+usenet@amorsen.dk>
References: <20201202021651.E8EE128C576A@ary.qy> <327860af-2fa7-63ee-4b89-6e7e383f3d53@crash.com> <2804da89-84d1-f601-9425-0b0d9baf6ae1@gmail.com> <1f6cae74-4eed-47f5-7249-e526bf1f5845@crash.com> <df11af30-2c27-0d69-97ba-bc058116c044@gmail.com> <87y2ig9t9i.fsf@orion.amorsen.dk> <CAJ4XoYeZXKKZpvtT2FcYouSsNur7=6d0PqSRnErVPQw6zCMW_A@mail.gmail.com> <CAL0qLwb=Vo63Q74r8N31STxbE2YN4+TMq_=yjr+cdMEJQ0m6Mg@mail.gmail.com> <CABa8R6uTadmZ-O23w-c3qMHmhofnsuB68_ski8-Q0OFDuQYZmw@mail.gmail.com> <1ddcc797fb34a9d45b9467a7a86c49751e013561.camel@aegee.org>
In-Reply-To: <1ddcc797fb34a9d45b9467a7a86c49751e013561.camel@aegee.org>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/9xyjwDI5Hgcs7PiaR7106EL18Uc>
Subject: Re: [dmarc-ietf] Ticket #39 - remove p=quarantine
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: Tue, 08 Dec 2020 17:18:29 -0000
On 12/8/2020 6:24 AM, Дилян Палаузов wrote:> Hello, > > I do no see the point of having all the discussions here, as nobody is > capable to read and understarstand all written emails in their whole > quantity. I personally do not follow the discussions anymore, apart > from reading the subjects… +1 Major Plus One. Its all deja vu. Optional reading. I'll use this opportunity to express my key summary concerns as a long time DKIM and SPF implementation and commercial DKIM/SPF product vendor. FWIW..... We have a Developer vs Administrative protocol design issue once again. Too many philosophical "Administrative" subjective opinions trying to burn their idea into how IETF protocols is written and how implementations should behave operationally from an admin standpoint. The DKIM POLICY model is a simple DNS lookup protocol, like SPF. It hasn't change since day one. DMARC is just the current rendition of the same thing since SSP - nearly 15 years - plus Reporting which was rejected for SSP and ADSP. Unlike SPF, what DKIM POLICY lacked 3rd party authorization protocol support. But we had discussed the idea of using SPF softfails as a way to link together with a valid DKIM result. I recall Microsoft was exploring this methods as one the early explorers of ADSP. I liked the concept and explored it myself by looking at a possible "fuzzy" logic of the results, for example: SPF PASS + DKIM PASS => Result PASS (confidence? 100%) SPF SOFTWARE + DKIM PASS => Result PASS (confidence? 80%) SPF NEUTRAL + DKIM PASS => Result PASS (confidence? 50%) SPF FAIL + DKIM PASS => Result PASS (confidence? 0%, SPF fail preempts DKIM?) But when it came to the new filtering protocols we were development, I was more interested in 100% or 0% deterministic protocol results. Anything in between is "fuzzy" and imo, can't make hard filtering unless we are now learning from the BIAS from Deep AI methods. For many, Pareto's 80% may be good enough for a filtering decision. It is well established, DKIM POLICY works for 1st party signatures. We know this since day one. The proof of concept was long set in stone and never to be killed. We documented it in the early initial DKIM WG work productions - Thread Analysis and the Functional specification: 2006 RFC4686.txt Analysis of Threats Motivating DKIM 2006 RFC5016.txt Requirements for a DKIM Signing Practices Protocol DKIM Policy is a powerful concept and in the words of one of the key cogs - "Its scary!" Yes, for direct 1 to 1 private mail, you have a very powerful way to protect against domain spoofing in the same way SPF protects against unauthorized transports from unknown machines. SPF has its "in-direct" issue with routing of transports which I called a "Node Transition" point. DKIM was initially marketed as a solution to the node transition problem. The stage was set. SSP with its 3rd party options, defined the ideas that a domain, like SPF, can describe which domain(s) can "notarize" the email. But we did not have a way to define the authorized 3rd party domain. The simple idea was to use tag= list, like a Access control list, for example acl=ietf.org, gmail.com which it reduced the need for another DNS lookup. The acl= tag works for a small well organization network. But it does not scale. ATPS was written to some some like of scalable using a zone record per 3rd party authorized domain. ATPS starts with a tag: atps=1 and if enabled, receiver will check for the signer domain authorization ATPS record. Does it work for all, no. But it works for many and its been in production since 2012. The DMARC or DKIM Policy protocol payoff does not come from positive passed results but rather with failed results because the protocol raises the bar by authorizing the receiver to reject or discard or quarantine a.k.a filter a message for the sake of the end-user. Side note: There are four states for mail transport: - Reject (SMTP does not accept it). - Accept (user sees it in inbox, may be filtered with other things) - Accept & Discard (lost to the user) - Accept & quarantine (move to spam box, outside the main inbox stream) The p= policy not only should keep quarantine, it should add p=discard Unfortunately, a key moment came, in RFC5016, section 5. item 10, when the beginning of this long 14+ year "fight" with Mailing list administrators started, imo. This was when all the heart aches became to occur, the major disagreements between Policy Advocates and Trust Advocates. Read it carefully. Its about local policy (duh), but this last minute item provision altered the future of DKIM POLICY. Every since then, we had his long debate of DKIM-POLICY Model vs Mailing List Systems. It basically lead to this protocol conclusion: DKIM POLICY does not work for Mailing List unless the Mailing List Server vendors supports and honors the DKIM POLICY model - period. If it does not, it will have trouble integrating into a new DKIM with optional restrictive policies world. I know of only one commercial List Software vendor, Wildcat! List Server, that supports the DKIM Policy for Restrictive Policies. It does not have the issue with in-direct mail submissions. New subscribers from restrictive domains are not allowed to subscribe. If already a member of the list, list members from restrictive domains can not longer post but they can continue to receive a distribution (iow, a read only member). For a long time, we had folks that believed "list servers" were so old in their ways they are not obligated to change or adapt to the DKIM policy model. I understand that. Wildcat! List Server is one of the older systems around. Yet, the same folks advocated making non-standard provision changes to intentionally ignore restrictive DKIM Policies, continue distributing changed and unprotected original domain mail by destroying the trust of the mail system by altering the "READ-ONLY" field 5322.From. Anyway, thanks for pointing this out. I second your concern. Its not pretty what is going on. I hope key folks with the IETF are made aware that this is not normal. I believe we need to recognize the need for augmented DKIM Policy Tag extensions that could do the various Product Support Features some people are looking for. I don't like ARC, too much overhead and its not addressing the key lack of authorized 3rd party domain concerns, but if GOOGLE wants to push this idea, than the ARC Protocol should extend DMARC with "arc=" related tags. I am on the fence of whether DMARCbis should mention ARC. I don't think so if its an experimental. I don't think we did this for a proposed standard to be referencing experimental work. But in any case, maybe the tag "arc=1: means that it promote SPF or DKIM fails? In theory when combining ARC to SPF and DKIM, we now have: SPF(4)+DKIM(2)+ARC(2) == Final Result(16) There are 16 combinations for SPF, DKIM and ARC states. Some will fold, some will not make sense. I won't argue the WG decision to add ARC to DMARC in some matter. But don't ram it down our throats. Allow domains to explore with an "ARC=1" tag in their DMARC record, then at some point in the future, as we learn more, it can be explored. But imo, we should not speak of a DKIM Policy Protocol as if ARC is a natural part of it. Thanks for reading. -- Hector Santos, https://secure.santronics.com https://twitter.com/hectorsantos
- [dmarc-ietf] Ticket #39 - remove p=quarantine John R Levine
- Re: [dmarc-ietf] Ticket #39 - remove p=quarantine Dave Crocker
- Re: [dmarc-ietf] Ticket #39 - remove p=quarantine Douglas Foster
- Re: [dmarc-ietf] Ticket #39 - remove p=quarantine Steven M Jones
- Re: [dmarc-ietf] Ticket #39 - remove p=quarantine Seth Blank
- Re: [dmarc-ietf] Ticket #39 - remove p=quarantine John Levine
- Re: [dmarc-ietf] Ticket #39 - remove p=quarantine Dotzero
- Re: [dmarc-ietf] Ticket #39 - remove p=quarantine Steven M Jones
- Re: [dmarc-ietf] Ticket #39 - remove p=quarantine Dave Crocker
- Re: [dmarc-ietf] Ticket #39 - remove p=quarantine Dave Crocker
- Re: [dmarc-ietf] Ticket #39 - remove p=quarantine John Levine
- Re: [dmarc-ietf] Ticket #39 - remove p=quarantine Laura Atkins
- Re: [dmarc-ietf] Ticket #39 - remove p=quarantine Steven M Jones
- Re: [dmarc-ietf] Ticket #39 - remove p=quarantine Дилян Палаузов
- Re: [dmarc-ietf] Ticket #39 - remove p=quarantine Alessandro Vesely
- Re: [dmarc-ietf] Ticket #39 - remove p=quarantine Dotzero
- Re: [dmarc-ietf] Ticket #39 - remove p=quarantine Dave Crocker
- Re: [dmarc-ietf] Ticket #39 - remove p=quarantine Dave Crocker
- Re: [dmarc-ietf] Ticket #39 - remove p=quarantine Dave Crocker
- Re: [dmarc-ietf] Ticket #39 - remove p=quarantine Benny Lyne Amorsen
- Re: [dmarc-ietf] Ticket #39 - remove p=quarantine Dave Crocker
- Re: [dmarc-ietf] Ticket #39 - remove p=quarantine Dotzero
- Re: [dmarc-ietf] Ticket #39 - remove p=quarantine Murray S. Kucherawy
- Re: [dmarc-ietf] Ticket #39 - remove p=quarantine Benny Lyne Amorsen
- Re: [dmarc-ietf] Ticket #39 - remove p=quarantine Dotzero
- Re: [dmarc-ietf] Ticket #39 - remove p=quarantine Jim Fenton
- Re: [dmarc-ietf] Ticket #39 - remove p=quarantine Jim Fenton
- Re: [dmarc-ietf] Ticket #39 - remove p=quarantine Jim Fenton
- Re: [dmarc-ietf] Ticket #39 - remove p=quarantine Laura Atkins
- Re: [dmarc-ietf] Ticket #39 - remove p=quarantine Dave Crocker
- Re: [dmarc-ietf] Ticket #39 - remove p=quarantine Todd Herr
- Re: [dmarc-ietf] Ticket #39 - remove p=quarantine Michael Thomas
- Re: [dmarc-ietf] Ticket #39 - remove p=quarantine Дилян Палаузов
- Re: [dmarc-ietf] Ticket #39 - remove p=quarantine John Levine
- Re: [dmarc-ietf] Ticket #39 - remove p=quarantine Brandon Long
- Re: [dmarc-ietf] Ticket #39 - remove p=quarantine John Levine
- Re: [dmarc-ietf] Ticket #39 - remove p=quarantine Дилян Палаузов
- Re: [dmarc-ietf] Ticket #39 - remove p=quarantine Hector Santos
- Re: [dmarc-ietf] Ticket #39 - remove p=quarantine Jesse Thompson
- Re: [dmarc-ietf] Ticket #39 - remove p=quarantine Brandon Long
- Re: [dmarc-ietf] Ticket #39 - remove p=quarantine Michael Thomas
- Re: [dmarc-ietf] Ticket #39 - remove p=quarantine Alessandro Vesely