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