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

Todd Herr <todd.herr@valimail.com> Tue, 03 August 2021 20:42 UTC

Return-Path: <todd.herr@valimail.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 737903A321F for <dmarc@ietfa.amsl.com>; Tue, 3 Aug 2021 13:42:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, 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 (2048-bit key) header.d=valimail.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 KIxm6q_W5wWt for <dmarc@ietfa.amsl.com>; Tue, 3 Aug 2021 13:42:25 -0700 (PDT)
Received: from mail-qt1-x834.google.com (mail-qt1-x834.google.com [IPv6:2607:f8b0:4864:20::834]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D3F93A321C for <dmarc@ietf.org>; Tue, 3 Aug 2021 13:42:25 -0700 (PDT)
Received: by mail-qt1-x834.google.com with SMTP id w10so28044qtj.3 for <dmarc@ietf.org>; Tue, 03 Aug 2021 13:42:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=id9AYzQGwP19LPKh7tnctfKEDk/NbOS0b2kpR/DwhWw=; b=bIxgnAf5TE1JOofW8q+3QVf++FZxDEFH5c/hUc4qk16aUMcT6CopVUKgv0i83TN0z1 bLUXgZhxZnGQ0sjpFri7NseOX8gTFwq2u8OL3Wv4u/sbVDXdU2ucNjCI0Tc6PVca0YEU 7UDfGOg5IaZZ2cboZqE0t9vGzkaJ1BxaY/Vs9POzO/CJqNUpc3sh58vhSmPjAy5XQ2My MbTKugx1SLR56d1R5InoN2ktSH1Ukegj33tMmFr7wXObhjFauDRWXLU1cWR+vr7gcSSQ NoOeZtoWfTFlkuWcmy1Pd3w/Q7ydSDPfHB6eY7ET1wqB8CiB8qCcn9tB8VbulhGH9Ndz iXjA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=id9AYzQGwP19LPKh7tnctfKEDk/NbOS0b2kpR/DwhWw=; b=t2cbUagmgzW5zr1YlT3G2oeTlG1qbsGzuRprC3oH1/K3iIq0999+qQfJlXumueMqEk cIyw/019eRmzmcwP6LA3pAtsV9zr8QHRu8OTjS/XP1hYzaJMS+QiqDRQnA+/usGCyZ3d tlRQNfhNE2+ztJIZDqRMR8CUNWPQQiGFKzbAX3whRXe2bfp7rnBtoMf5HI9oFWvo5A2N 4hJC7Yy6hc6e4vwhRH0aO+6dcve0yuHAs5lBoHTsRg90rSzTUAdyVHp6cg0jaD5Qzx6D k7lAtDh6FgfaCraYB01gSEz64pxjgrVHt20NLIcUSAuQ5+0yoRxYFx7MON6+8H8v4a2j lS4A==
X-Gm-Message-State: AOAM533lEBr392VPFy9mZ7VwFvcka4ksV74WzLl5EzxeG35+16aEta0Q 87otAjwc8PB64RrGOQaZE6o1PzzmlpSVeZu6WJpHbfoT+kk=
X-Google-Smtp-Source: ABdhPJyt522/o1mfqIP9NWByYxaID/cI1lUHM+tXOcrGMabcQtGnin9hxN7n/yTjTYFxDlk2HqUY5F5eBO9mu7Xzo3w=
X-Received: by 2002:a05:622a:14ce:: with SMTP id u14mr20038996qtx.208.1628023343372; Tue, 03 Aug 2021 13:42:23 -0700 (PDT)
MIME-Version: 1.0
References: <CAHej_8=LL_KWcVYnc2quYSGMnQF5bdoerDtTZZm1yGjxjCqW1Q@mail.gmail.com> <20210803021005.EE5CF257D352@ary.qy> <CAHej_8k0rZHY02_mAMfc19dUOVREbd_WdTr5whUuNHmggx+cdA@mail.gmail.com> <CALaySJKb32r36Eq89_bM_dv4NeMtPmkgzHJX=AW+QVM-skHoVQ@mail.gmail.com> <CAHej_8kFB+icKyhTNUhbAV39Fa5KJBAXDb+REQM_1CPaUnkXzg@mail.gmail.com> <5cb4c752-f634-a385-06b0-4d9af6a00c8d@gmail.com>
In-Reply-To: <5cb4c752-f634-a385-06b0-4d9af6a00c8d@gmail.com>
From: Todd Herr <todd.herr@valimail.com>
Date: Tue, 03 Aug 2021 16:42:07 -0400
Message-ID: <CAHej_8=OSqFGU-DGOXNYeNNWAACg8bjKTQq8YH_Ccqc8RGMs5g@mail.gmail.com>
To: IETF DMARC WG <dmarc@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000001171cd05c8adb984"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/HLXupYGTdA4wK8xKYv2IDvxNlvM>
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: Tue, 03 Aug 2021 20:42:31 -0000

On Tue, Aug 3, 2021 at 3:59 PM Dave Crocker <dcrocker@gmail.com> wrote:

> On 8/3/2021 12:54 PM, Todd Herr wrote:
> > 2. Define a tag named "t", in a fashion somewhat similar to the t= tag
> > available for DKIM public key records, as follows:
>
> A reasonable suggestion, based on the extended discussion.
>
> I have a devil's advocate question, with two purposes.  One is because I
> really am interested in understanding this better.  The second is
> because it might prompt the additional of some explanatory text, to that
> future readers of the spec will also understand this better:
>
> My question:  what does this accomplish, of significant benefit, that
> p=none does not?
>

To cite one example, "p=quarantine; pct=0" triggers rewriting of the
"From:" header at some intermediaries (such as Google groups) where
"p=none" does not.

I cannot articulate how such rewriting helps a domain owner eventually move
to a policy of p=quarantine or p=reject with no pct tag.

That doesn't mean that I think it's not a useful setting on the journey
from p=none to something stronger; it only means that I can't remember the
particulars of the rewriting that takes place and how the domain owner can
take advantage of information revealed by the rewriting in order to
eventually remove the pct tag.

It might be this:

   - p=none: I as a domain owner receive aggregate reports showing all mail
   that I originated (and obviously stuff I didn't), with some of my
   originated mail flowing through intermediaries
   - p=quarantine; pct=0: I as a domain owner receiving reports showing all
   mail that I originated except for mail that flowed through intermediaries
   that do From: header rewriting. I can then examine the differences in the
   reports, suss out which intermediaries aren't rewriting the From: header,
   and decide if I care enough about the volume I'm sending to those
   intermediaries to have it affect my decision to move to a stronger
   assessment policy.

The above all pre-supposes that p=quarantine or p=reject will also cause
those intermediaries that rewrite when they see pct=0 to rewrite when they
don't. That may be a valid assumption, but I'd rely on someone with more
knowledge of the state of play here to speak to the topic.

-- 

*Todd Herr* | Technical Director, Standards and Ecosystem
*e:* todd.herr@valimail.com
*m:* 703.220.4153

This email and all data transmitted with it contains confidential and/or
proprietary information intended solely for the use of individual(s)
authorized to receive it. If you are not an intended and authorized
recipient you are hereby notified of any use, disclosure, copying or
distribution of the information included in this transmission is prohibited
and may be unlawful. Please immediately notify the sender by replying to
this email and then delete it from your system.