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

Douglas Foster <> Sun, 01 August 2021 12:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EFA923A387B for <>; Sun, 1 Aug 2021 05:03:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, 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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id kLtSs1la0VOz for <>; Sun, 1 Aug 2021 05:02:56 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::32b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1690E3A3878 for <>; Sun, 1 Aug 2021 05:02:55 -0700 (PDT)
Received: by with SMTP id f20-20020a9d6c140000b02904bb9756274cso2864839otq.6 for <>; Sun, 01 Aug 2021 05:02:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=D1s5SySEuren3gSMoxDnBJjs4xz2QIuRtvvBc+TbsZg=; b=aHUAAWrjqO9WLe4nQ3pI3kS8Eas9IKvDxJ30IgJA6aOjSV280iobdBQEcHfGv3Pb8V DXEG9qaVIypVOuwp8e1fSHFFZIbLcUdBZvpGe1tqkDpwvX11mUoGVZjJwEAAZxe1kf/m pTKlWlykNAFVTBP1icBUMsc+TN5M9WG69IgmXjJD8APSVsqR2MPAHrUCOQIbFCUv3CUo XcbLJiw2Q7S8C0ojpj0Wfg4QHcKB/Iwoal3p09q7RvvBe2Xv8AAZ4NG7z9EWtlInSqw7 WgAKEtlAHTV422vK7PI039EMIBk5sjE6NBT59tlrhzjQJ3I0cwZ5JUPTgvUOdRVrFwcv MivQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=D1s5SySEuren3gSMoxDnBJjs4xz2QIuRtvvBc+TbsZg=; b=TBMTxi6FrI5iuvm+49k5hIa+gKhuHg1hJ1zvshXes8jFMGwt0r7wB0J83gOGKyjUek YeikuA1Q0IBXVWlhh+BY+m4Mn6+D++mWVVXtJG6Ptb1mrghVhtWy+tYicu2cIm3Mh/Th aNwPtEtq4dVE16IYxtLWIyuT9mm71HyLnQKvFv+gqXwoM1QvXXzyS2ffjEgC2oi++VNw 7lE7bxEtAA5zryz+u+W9wBn+Qlq9B1N4EEQK5Ni6809PJrefvUS3b/nhL6AD66gORg6t kx1K7kdPGeemFR7lQcDOMnTscEFQocOpvuzAc+odNOiR3WBfggyz4bPlbYBykkfQbujA miDg==
X-Gm-Message-State: AOAM5316im0iw0iLynsUR80L7XOdad/C4ICAx9Cprn7GNi6fnAj0Df6w 86dGaDJD1gBX56obAo0ukEeJAVZFz77/S5NvG4FpD50U
X-Google-Smtp-Source: ABdhPJzltZ72zkPBofw74HII2xW3gYE3MlWWsbSglntvOA4L85jmv36xw/+ZZ7ytbGGyzlFZ9CCHhT5LHOaLLcRr9cg=
X-Received: by 2002:a9d:7010:: with SMTP id k16mr8071061otj.298.1627819374188; Sun, 01 Aug 2021 05:02:54 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Douglas Foster <>
Date: Sun, 1 Aug 2021 08:02:44 -0400
Message-ID: <>
Content-Type: multipart/alternative; boundary="0000000000008e9aae05c87e3b29"
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: Sun, 01 Aug 2021 12:03:01 -0000

>From munging can be a de-facto standard, but I don't think it can ever
obtain IETF endorsement.

As far as I can tell, IETF has never endorsed BATV or SRS, or any other
encoding scheme which lengthens the local-part of the address.  I expect
>From munging to encounter the same obstacle.

We have an architectural rule which allows 64-characters, at origination,
for the local-part name.  This also prohibits 65 character or longer names
at reception.    Any encoding scheme which adds content in transit can make
a compliant name become non-compliant.   Multiple encoding events can
extend the local-part to a length that is not easily predicted.

I realize that in practice, most local-part names are short enough to leave
room for expansion, and many domain names are short enough to allow them to
be inserted into the local-part without triggering a length problem.   But
the potential problem exists, and I have not seen an encoding scheme
definition which says how to handle the possibility.

If From-munging is ever endorsed, I would like to have the unmunged name
captured in an ARC, set so that an evaluator can reliably recover it from
an authenticated (signed) header element.

Doug Foster

On Sat, Jul 31, 2021 at 5:55 AM Дилян Палаузов <>

> Hello,
> 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.
> Greetings
>   Дилян
> 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
> >
> >
> _______________________________________________
> dmarc mailing list