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

Todd Herr <todd.herr@valimail.com> Mon, 02 August 2021 19:49 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 CCE263A1998 for <dmarc@ietfa.amsl.com>; Mon, 2 Aug 2021 12:49:36 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 5pltxT-a-F-r for <dmarc@ietfa.amsl.com>; Mon, 2 Aug 2021 12:49:31 -0700 (PDT)
Received: from mail-qt1-x82e.google.com (mail-qt1-x82e.google.com [IPv6:2607:f8b0:4864:20::82e]) (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 122013A1965 for <dmarc@ietf.org>; Mon, 2 Aug 2021 12:49:30 -0700 (PDT)
Received: by mail-qt1-x82e.google.com with SMTP id l24so12477350qtj.4 for <dmarc@ietf.org>; Mon, 02 Aug 2021 12:49:30 -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=fR1QrNkyp+AJMQ8maDs0XfAjxcwDcyTkQ0kw9FOWBc0=; b=IrX/jp+3KX21ZVmdHX0PTP6nwR/mq6muLmVj6Yid9UJYaNTjSt8XMA/881GAL87ARf +yyvPQYUO3cww8tLMSqtK4AiJ9MTWV8M5UmwKtjEQmdVPUF8eSXtQIcL0+l35flQv7NN d2cp315+WbUG5eBz7kQ1TFFu89dpupCORLOWQPW2Jl/1m5kM2zryX0DwSuOtmcKrbf76 9cSKcSWSOS0FsmtXnlhaKC4lkBdXeONdf6XpqWNfeXoKR/Wk2Spvi2T1Fy44AR34aJgJ 7UGi+AkKOO0Ll+f6pgBVa1QOvAzl/6gbuhU5AalPQaUhBHrYqwtEXvDi1HDrsTfVuI+r LlQw==
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=fR1QrNkyp+AJMQ8maDs0XfAjxcwDcyTkQ0kw9FOWBc0=; b=V7JNlRvBQ2FRe/3p8AKRawM9nZxfHOkd1eS/+XC6MhLiCyPmTLwsWc0v/J62a64XFE e/dz3E2lSei69m6KIoxjJlf/1JJgNRuhhEGZVMHZw5tEbUS8Zio112qjFMgvaNYTW7Sy DcN/Wd/h6ZPjN4XuTeksklsZ5KVk1TU9oqb/1cvp6gDGHyE82ykskUHWjom94toiZ1jQ 2RTjt20rE7Pali7ZlfIs9xDlCVP1787CgQmbDLwiF7g5DTJ8ip6LRsL/FNytgQ2ENXcD NaeIgtG6XdrbiokT3YHHoWvMFQ0sIdNd867CfsOPOLS+9WL67oAuXuG9U/78sYtY8tQR +oSA==
X-Gm-Message-State: AOAM531zHedDECcxDUDUIy7mFeBd4XVWiUXSkveKOMcNfDq2jpTWFhr7 KCv4B8Nqw29rH3pguI+PpNmBBoHeysqyc+apDXId3Hy8VH/6cw==
X-Google-Smtp-Source: ABdhPJyeKbFk20Oq1J1lrt6GFMzmOm3jN5BjKf3GTzBxUBb0jNEFZgx9S1YXNyVNbv9PLAJC1qx9epqG5vcLMZAAvSE=
X-Received: by 2002:ac8:7f8c:: with SMTP id z12mr15810154qtj.224.1627933768914; Mon, 02 Aug 2021 12:49:28 -0700 (PDT)
MIME-Version: 1.0
References: <CAHej_8m4W_k_r9SV6reNJA7aMGFCkK451tjvQGtrPNwRtJwC8A@mail.gmail.com> <20210731203844.1DBB42566507@ary.qy>
In-Reply-To: <20210731203844.1DBB42566507@ary.qy>
From: Todd Herr <todd.herr@valimail.com>
Date: Mon, 2 Aug 2021 15:49:12 -0400
Message-ID: <CAHej_8=LL_KWcVYnc2quYSGMnQF5bdoerDtTZZm1yGjxjCqW1Q@mail.gmail.com>
To: IETF DMARC WG <dmarc@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000003ada405c898de59"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/P_iLOn54CP7YU-s4Myv1aWRkuGY>
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: Mon, 02 Aug 2021 19:49:44 -0000

On Sat, Jul 31, 2021 at 4:38 PM John Levine <johnl@taugh.com> wrote:

> I'd make it a lot simpler:
>
>    pct:  (plain-text integer; OPTIONAL; default is 100).  For the
>       RFC5322.From domain to which the DMARC record applies, the "pct"
>       tag describes what receivers are requested to to do with unaligned
> messages.
>       This parameter does not affect the generation of DMARC reports.
> Possible values are as follows:
>
>       0:  A request to not apply the policy, but for message forwarders
>           to do whatever message rewriting they do that is intended to
> avoid
>           sending DMARC unaligned mail.
>
>       100:  The default, a request to apply the policy as specified.
>
>       Any other value: results are undefined.
>
>
> I like simple, but I also like the idea of a separate section that
discusses the history of the pct tag and why the old values won't work any
longer.

So, how about this:

   pct:  (plain-text integer; OPTIONAL; default is 100).  For the

      RFC5322.From domain to which the DMARC record applies, the "pct"

      tag serves as a signal to the actor performing DMARC validation

      checks as to whether or not the domain owner wishes the assessment

      policy declared in the "p=" tag to actually be applied.  This

      parameter does not affect the generation of DMARC reports.

      Possible values are as follows:


      0:  A request that the actor performing the DMARC validation check

         not apply the policy, but instead apply any special handling

         rules it might have in place.  See Section 6.7.4 for further

         details.


      100:  The default, a request to apply the policy as specified to

         any message that produces a DMARC "fail" result.


And this:


6.7.4.  History of the "pct" Tag


   An earlier experimental version of the DMARC protocol [RFC7489]

   specified all integers from 0 to 100 inclusive as valid values for

   the pct tag.  The intent of the tag was to provide domain owners with

   a method to gradually change their preferred assessment policy (the

   p= tag) from 'none' to 'quarantine' or from 'quarantine' to 'reject'

   by requesting the stricter treatment for just a percentage of

   messages that produced DMARC results of "fail".


   Operational experience showed that the pct tag did not function as

   intended due to many factors, and so this version of the DMARC

   protocol has eliminated all possible values save for "100", which

   remains the default, and "0".  The value of "0" took on unintended

   significance during the experimental stage as a value used by some

   intermediaries and mailbox providers as an indicator to either

   deviate from standard handling of the message and/or to alter the

   substance of reports generated, and these "custom" actions proved too

   valuable to the email community to remove from this version of the

   protocol.




-- 

*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.