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

From: Todd Herr <[email-masked]>
Date: Fri, 30 Jul 2021 16:06:39 -0400

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

-- 

*Todd Herr* | Technical Director, Standards and Ecosystem
*e:* [email-masked]
*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.

---

From: Douglas Foster <[email-masked]>
Date: Fri, 30 Jul 2021 20:12:56 -0400

This language addresses my original concern.

You have a typo at this point:
... cases, in can result in...
and of course it should read
...cases, it can result in...

Since PCT is being removed, I would like to provide something for domain
owners that are struggling to complete implementation safely.   I think
what they would most appreciate would be for recipients to use SMTP
extended result enhanced status codes.   Others have already defined
appropriate codes to communicate whether or not a message passes
authentication, and how.

Unfortunately, it seems the extended status codes have very limited
deployment.   When I searched my recent history, I could only find codes
2.0.0 and 2.6.0, which communicate nothing incremental.

Would it be reasonable to add language saying that we RECOMMEND that
evaluators use extended status codes, for both accepted and rejected
messages, to indicate the message authentication status?   We could
highlight the codes that are particularly relevant to this need.

Doug Foster

On Fri, Jul 30, 2021 at 4:07 PM Todd Herr <todd.herr=
[email-masked]> wrote:

> _______________________________________________
> dmarc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmarc
>

---

From: Alessandro Vesely <[email-masked]>
Date: Sat, 31 Jul 2021 11:39:54 +0200

On Fri 30/Jul/2021 22:06:39 +0200 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:

I still dislike this limitation.  I previously showed that users seem to change 
pct= with some salt.  In addition, how should implementations amend their code? 
  What shall a receiver do if it finds intermediate values of pct?

I'd keep allowing intermediate values.  Substitute /Possible values are as 
follows:/ with /RECOMMENDED values are as follows:/.

For case 0:

YOUR TEXT:

MY PROPOSED ALTERNATIVE:
      0:  A request that messages producing a DMARC "fail" result never
          have the specified policy applied.  The special meaning of
          this value is to have mailing lists which discriminate message
          handling by author's domain policy apply From: munging
          (see [Section X.Y.Z]) while final receivers still apply no
          policy.

Best
Ale
--

---

From: Дилян Палаузов <[email-masked]>
Date: Sat, 31 Jul 2021 12:55:25 +0300

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:
>

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 31 Jul 2021 11:27:45 -0700

> 2.0.0 and 2.6.0, which communicate nothing incremental.

Indeed; I would like to understand what 2.6.0 is meant to convey.  As I
read the IANA registry entries, "2" means success but "6" means there was a
media type error.

> highlight the codes that are particularly relevant to this need.

I'm not sure about RECOMMENDED, but reminding readers of this mechanism for
providing additional information seems at least harmless to me.

If we say RECOMMENDED, I'd be inclined to think we should say something
about both producers of these codes and consumers of them, to encourage
interoperability.  There's no point in making a strong push toward
generating them if nobody has any incentive to do something with them when
they're observed.

-MSK

---

From: "John Levine" <[email-masked]>
Date: 31 Jul 2021 16:24:25 -0400

>read the IANA registry entries, "2" means success but "6" means there was a

I think it's supposed to mean "I accepted your message but I wouldn't have if I were
enforcing DMARC p=none".

Since this would be a gift to spammers trying to probe and evade filters, I find it
very unlikely anyone would implement it, so no.

R's,
John

---

From: "John Levine" <[email-masked]>
Date: 31 Jul 2021 16:38:41 -0400

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.

It makes no sense to say anything about how DMARC reports are received, they're received however they 
are.  If there were some way to give them a free pass, whaddaya know, spam would start looking
like DMARC reports.

The way this is written, p=none pct=0 requests rewriting, which I don't think is wrong.  It doesn't mean
anything else now.

R's,
John

---

From: Douglas Foster <[email-masked]>
Date: Sat, 31 Jul 2021 19:47:12 -0400

Ale, I understand your concern but I don't know that it can be solved.

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.   However, DMARCv1 was written with a presumed requirement for
participating recipients to follow that algorithm.

Given my expectations around actual recipient behavior, it seems
unreasonable to tell domain owners to expect a different set of behaviors
than what will actually occur.  I do not want to mislead.

During evaluation, my practice will be to treat any value other than 100 as
equal to zero, because it means that the sender does not have enough
confidence in his situation to be able to provide me with useful
information.   It does not mean that I will ignore the sender
authentication failure.

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.   In
practice, I quarantine some messages and let some messages through, then
periodically go back and adjust my policies after reviewing actual message
details.

Doug Foster

On Sat, Jul 31, 2021 at 5:40 AM Alessandro Vesely <[email-masked]> wrote:

> specifically the

---

From: Douglas Foster <[email-masked]>
Date: Sat, 31 Jul 2021 20:42:09 -0400

2.6.0 really is a mystery to me.  The domain under study uses p=reject and
is getting 100% authenticated in the RUA reports, so it does not fit John's
theory.

I always get 2.6.0 from outlook.com servers and a few other destinations.
 So perhaps it is just their version of "OK so far, but I may block you
later in the evaluation process."

I would be interested if anyone else has data on extended status codes.  If
it seems too off-topic for the whole group, you can send to me directly.

Doug