Re: [dmarc-ietf] Some Proposed Language for a New pct Tag Defintion

Alessandro Vesely <vesely@tana.it> Sun, 01 August 2021 09:13 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 A5D403A335F for <dmarc@ietfa.amsl.com>; Sun, 1 Aug 2021 02:13:22 -0700 (PDT)
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 AwcCdr2KSD-D for <dmarc@ietfa.amsl.com>; Sun, 1 Aug 2021 02:13:17 -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 1CAE83A335D for <dmarc@ietf.org>; Sun, 1 Aug 2021 02:13:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1627809192; bh=/AqZJz0lCHG/sVMurMFVDoCD2Jli6oWL8O5nl/G5QyE=; l=1229; h=To:References:From:Date:In-Reply-To; b=BNQPtcDNv6gcAVYDMu8eptEUz+HbFagiFQG5HmuzvHXA9EiyqNDZKG88a/T0aCzAB cfWpW72sBjdcugcbPwhqzDfzpKR7cluKcBpJwf5iGRozJEe+BjOMnu5tlX278LIyJ4 HaRM9DwhEy68qfHXJW4kFYLtAtcOqwksZzfdZAqXwntUPcv7Ke03+87PXmzKK
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 00000000005DC14E.00000000610665A8.00006A08; Sun, 01 Aug 2021 11:13:12 +0200
To: dmarc@ietf.org
References: <CAHej_8m4W_k_r9SV6reNJA7aMGFCkK451tjvQGtrPNwRtJwC8A@mail.gmail.com> <6e96de62-f387-bb42-a5da-0b7f74674a02@tana.it> <CAH48ZfzjQxRzqpGD9GqgeJcJ25V1cA3ke-x-N-bxO9--Lm4NUQ@mail.gmail.com>
From: Alessandro Vesely <vesely@tana.it>
Message-ID: <6a5ba0e4-7bc1-0dee-4bb1-4fa1678d5c70@tana.it>
Date: Sun, 01 Aug 2021 11:13:12 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0
MIME-Version: 1.0
In-Reply-To: <CAH48ZfzjQxRzqpGD9GqgeJcJ25V1cA3ke-x-N-bxO9--Lm4NUQ@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/H1o__x7DQtz9ILkkDlHvENKkApo>
Subject: Re: [dmarc-ietf] Some Proposed Language for a New pct Tag Defintion
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: Sun, 01 Aug 2021 09:13:23 -0000

On Sun 01/Aug/2021 01:47:12 +0200 Douglas Foster wrote:
> 
> My core objection is the partial-enforcement algorithm.   I cannot believe that 
> it would be wise for me, or any other receiver, to implement that algorithm.


Why not?  What's wrong with it?

if DMARC fail and (p=quarantine or p=reject) then
    if (random mod 100) < pct then
       apply policy


> In the face of ambiguity, the only way to get a correct disposition is to 
> collect more data.    If I had more time, I would quarantine all 
> unauthenticated mail until I could determine whether the sender should be 
> authenticated by local policy or blacklisted by local policy.


If you collect millions DMARC-fail messages every day for some years and 
calculate the exact percentage you will get the same result as the algorithm 
above applied on each message as it arrives.  See:
https://en.wikipedia.org/wiki/Monte_Carlo_method#Overview

If you collect unauthenticated message, besides the implied delay, you'll have 
the problem of selecting which ones to select until the percentage is 
fulfilled.  The first ones?  Distribute evenly in time or in size?  Select the 
ones with highest score?  Luckily we don't have to do so.


Best
Ale
--