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

Дилян Палаузов <> Sat, 31 July 2021 09:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A945D3A2009; Sat, 31 Jul 2021 02:55:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
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, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (4096-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id JRcZ4fs0aDdF; Sat, 31 Jul 2021 02:55:36 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D9F553A2007; Sat, 31 Jul 2021 02:55:35 -0700 (PDT)
Authentication-Results:; auth=pass (LOGIN)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=k4096; t=1627725326;; bh=shmCHY9tXPjbvSo3IsHO0sB3aoYLIAwaTzVvG3zuY9Q=; h=Subject:From:To:Date:In-Reply-To:References; b=jkrBaCvQVKmOD7q9il0OSadUvbhnegaXzoY3taHDy8D8AHXua1CP+WESLBIyq/IEE EMd7RFlO34KZ2aqJZgfEZN9EF4CaW9A1ZjjU0npGm+dEsH5tEcyfZ59at6ACaaz4Fv lfp+HcrpFLmxU+G5tmt13VXPmtVRjZKipHQTXIfleh+vw9DKVz4F1J8zvlQfo9YES3 Rp15FQPenpguIofr5lASSEIDw4jhHXjRJLX5zru3lHH1+kRvl65ZwJISc1RAanqgyE JpDgbug/tPtXzKxqyADK44bpGi5bIPDagDQi0b/ft2fCi8KtZ+gdadMQIeSHnHkLhO TvPLLtS1/DuHyiBN16VZziEizA+dAE+hmHY7484BNzD5NrA8V+jWttDzddrK9e3JPA BcZ9QbfIq+W/zcMfvlpIvEcY+1ulbAVSJYou9ialgcMiaFjPNYFpRjHX8ZqaY9xCT3 U/pFkjeVt24jCJZH7RI8O2Wfdkju8O2s6hBavnMKOb5PW5pKpFlPLylZfOrwJD3gQu k1m9GyUov/QT+ZLA+7MmdaBU47NfXBPudjP0fbSygBts9naxEIKWq+F8TCnC7f6mA4 nO5Ow5/tknMqDDtPnhbBfiOiGyUv0lBD8/jjDPFdm/gncp5YkqF9TTIobOOd/LLQnn 9gHHnRgUaGQdEa6kG0+BnjPY=
Authentication-Results:; dkim=none
Received: from [] ( [] (may be forged)) (authenticated bits=0) by (8.15.2/8.15.2) with ESMTPSA id 16V9tP8p3586715 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sat, 31 Jul 2021 09:55:26 GMT
Message-ID: <>
From: =?UTF-8?Q?=D0=94=D0=B8=D0=BB=D1=8F=D0=BD_?= =?UTF-8?Q?=D0=9F=D0=B0=D0=BB=D0=B0=D1=83=D0=B7=D0=BE=D0=B2?= <>
To: Todd Herr <>, IETF DMARC WG <>
Date: Sat, 31 Jul 2021 12:55:25 +0300
In-Reply-To: <>
References: <>
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.41.2
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Archived-At: <>
Subject: Re: [dmarc-ietf] Some Proposed Language for a New pct Tag Defintion
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 31 Jul 2021 09:55:41 -0000


for me this wording of pct=0 is not clear enough, why the value is
necessary.  Why the value is necessary can be explained by:

When seeing pct=0 mail intermediaries should munge the From: header. 
This allows mail operators to detect problems with DMARC deployment,
before strict DMARC policy is applied.


On Fri, 2021-07-30 at 16:06 -0400, Todd Herr wrote:
> Following on to the recent discussion about the pct tag, and
> specifically the disallowing of any values other than 0 and 100, I
> propose the following text and look forward to your comments:
>    pct:  (plain-text integer; OPTIONAL; default is 100).  For the
>       RFC5322.From domain to which the DMARC record applies, the
> "pct"
>       tag is the percentage of messages producing a DMARC result of
>       "fail" to which the Domain Owner wishes its preferred handling
>       policy be applied.  However, this MUST NOT be applied to the
>       DMARC-generated reports, all of which must be sent and received
>       unhindered.  Possible values are as follows:
>       0:  A request that zero percent of messages producing a DMARC
>          "fail" result have the specified policy applied.  While this
> is
>          seemingly a non-sensical request, this value has been given
>          special meaning by some mailbox providers and intermediaries
>          when combined with "p=" values other than "none".  In those
>          cases, in can result in changes to message handling, and/or
>          DMARC reporting for the domain publishing such a policy.  In
>          some instances of altered reporting, it is possible that the
>          altered reports may reveal intermediaries whose handling of
> the
>          domain owners' mail could cause it to produce a DMARC result
> of
>          "fail" when it reaches its final destination.
>       100:  The default, in which a request is made that every
> message
>          that produces a DMARC "fail" result will be subject to
>          application of the specified policy.
> I'll check on this thread on Monday to see where things stand...
> _______________________________________________
> dmarc mailing list