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

From: Alessandro Vesely <[email-masked]>
Date: Sun, 1 Aug 2021 11:13:12 +0200

On Sun 01/Aug/2021 01:47:12 +0200 Douglas Foster wrote:
> 
> 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.

Why not?  What's wrong with it?

if DMARC fail and (p=quarantine or p=reject) then
    if (random mod 100) < pct then
       apply policy

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

If you collect millions DMARC-fail messages every day for some years and 
calculate the exact percentage you will get the same result as the algorithm 
above applied on each message as it arrives.  See:
https://en.wikipedia.org/wiki/Monte_Carlo_method#Overview

If you collect unauthenticated message, besides the implied delay, you'll have 
the problem of selecting which ones to select until the percentage is 
fulfilled.  The first ones?  Distribute evenly in time or in size?  Select the 
ones with highest score?  Luckily we don't have to do so.

Best
Ale
--

---

From: Douglas Foster <[email-masked]>
Date: Sun, 1 Aug 2021 08:02:44 -0400

>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 Дилян Палаузов <[email-masked]>
wrote:

> 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
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/dmarc
>
> _______________________________________________
> dmarc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmarc
>

---

From: Douglas Foster <[email-masked]>
Date: Sun, 1 Aug 2021 14:56:55 -0400

Ale, I tried to explain my objections in the original post.   However, it
is a very important question, so I am happy to revise and extend my
points.    Forgive me for being long-winded , I am trying to be thorough
because I see problems at many levels.

Doug Foster

Random Guessing can increase the volume of wrong decisions.

The basic math does not work.   Assume that a message sequence has a
probability P of being unwanted, and a probability of Q = 1-P of being
wanted.   Does it make sense to use a random number based on P to discard
messages?

Probability of outcomes:

·         P*P – unwanted messages, correctly blocked

·         P*Q – unwanted messages, incorrectly accepted

·         Q*P – wanted messages, incorrectly blocked

·         Q*Q – wanted messages correctly accepted

Total error rate is 2*P*Q.   We have exchanged a one-sided error (allowing
P unwanted messages) for a two-sided error distribution?    Does it improve
the overall error rate.   Specifically, when is 2*P*Q < P ?

Cancelling P from both sides (P>0) yields 2*Q < 1 and Q < 0.5

If the message stream is more than 50% unwanted, then random guessing might
produce fewer total errors than allow-all.   If the message stream at least
50% wanted, then random guessing produces inferior results.

Other filtering stages will raise Q and lower P

Since the specific issue is failed DMARC Authentication, we also need to
consider how this task fits into the evaluation process.    I believe my
process is typical:

·         First, messages from known-bad senders are blocked.

·         Second, sender authentication is performed, at which point some
messages may be discarded.

·         Third, content filtering is applied, and suspicious content is
blocked.

·         Fourth, end-user activity occurs, where some messages are ignored
or discarded.

One effect of the first stage is that it lowers P and raises Q.   During
sender authentication, Q is likely to be above 50% even if the initial mail
stream has a Q below 50%.

If a false negative occurs during sender authentication, causing an
unwanted message to be allowed, the message may be blocked during content
filtering or it may be ignored by the user.  Consequently, if the
probability P is applicable during sender authentication, the probability
of a threat being successful is less than P.

Random guessing will increase the volume of unrecoverable errors.

If a false positive occurs during sender authentication, causing a wanted
message to be blocked, there is no opportunity for recovery.  Therefore,
false positives are a greater problem than false negatives, and the random
guessing algorithm has the effect of replacing false negatives with false
positives.

Sender’s probability has no relation to Evaluator’s probability

For any single domain, incoming messages can be broken into three
categories:

·         Legitimately-sourced messages which arrive with valid credentials.

·         Legitimately-sourced messages which arrive with failed
credentials.

·         Impersonation messages which arrive with failed credentials.

For simplicity, assume that sender and receiver interests are aligned – the
receiver wants to accept all legitimately-sourced messages from the
domain.   Since the sender is moving toward P=REJECT and the recipient
wants to enforce P=REJECT, we will also assume that mailing lists are not
part of the mail stream.

Neither sender nor receiver know the volume of unwanted impersonating
messages.   This means that the denominator is unknown, but would be
determined by the volume of impersonation + legitimate messages.   The
numerator for computing wanted message rates (Q) is all of the legitimate
messages.  The numerator for computing unwanted message rates (P) is all of
the impersonation messages.

Because the recipient wants all of the legitimately-source messages, the
percentage of legitimate messages sent with imperfect credentials is
irrelevant.

Assuming that the source domain knows the volume of messages which are sent
without complete credentials, and publishes a percentage based on that
knowledge.    Can the evaluator benefit from that information?   I don’t
think so.

Credentials at origin are determined by whether the source is configured to
apply correct SPF and DKIM credentials or not.   The source domain could
determine message volumes by server to compute a weighted statistic for
percentage of messages with correct credentials.    But any single
evaluator will need see the same weighted distribution of message
sources.   It may not receive any messages from non-compliant servers, it
may receive messages only from non-compliant servers, or any other possibly
weight distribution.   Applying the source-domain’s percentage estimate to
the received message stream would only make sense if the weighting is
comparable.

More importantly, the assumed goal for both sender and receiver is to have
all legitimately-sourced messages to be accepted.  Arbitrarily blocking
some wanted messages, for the sake of notifying about credentialling
problems, works against the goal of the evaluator and his user base.  It is
too high a price to pay.

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 2 Aug 2021 12:45:40 +0200

On Sun 01/Aug/2021 20:56:55 +0200 Douglas Foster wrote:
> Ale, I tried to explain my objections in the original post.   However, it is a 
> very important question, so I am happy to revise and extend my points.    
> Forgive me for being long-winded , I am trying to be thorough because I see 
> problems at many levels.

You're adding useless complications.

> wanted.   Does it make sense to use a random number based on P to discard messages?
> 
> Probability of outcomes:
> 
> ·P*P – unwanted messages, correctly blocked
> ·P*Q – unwanted messages, incorrectly accepted
> ·Q*P – wanted messages, incorrectly blocked
> ·Q*Q – wanted messages correctly accepted
> 
> Total error rate is 2*P*Q. We have exchanged a one-sided error (allowing P 
> unwanted messages) for a two-sided error distribution?    Does it improve the 
> overall error rate.   Specifically, when is 2*P*Q < P ?
> 
> produce fewer total errors than allow-all.   If the message stream at least 50% 
> wanted, then random guessing produces inferior results.

In plain English, if you have more spam than ham, then blocking at random is 
correct in most cases.  That's an obvious statement which adds nothing to the 
discussion.

> ·First, messages from known-bad senders are blocked.
> ·Second, sender authentication is performed, at which point some messages may 
>  be discarded.
> ·Third, content filtering is applied, and suspicious content is blocked.
> ·Fourth, end-user activity occurs, where some messages are ignored or discarded.
> 
> One effect of the first stage is that it lowers P and raises Q.   During sender 
> authentication, Q is likely to be above 50% even if the initial mail stream has 
> a Q below 50%.

The purpose of authentication is to recognize senders by name rather than by IP 
number.  Thus, according to the sense of "known-bad senders", authentication 
can be considered a prerequisite of the first stage.  If authentication fails, 
you don't know who the sender is, therefore you don't know if it's good or bad.

> If a false negative occurs during sender authentication, causing an unwanted 
> message to be allowed, the message may be blocked during content filtering or 
> it may be ignored by the user.  Consequently, if the probability P is 
> applicable during sender authentication, the probability of a threat being 
> successful is less than P.

No.  A successful authentication of a spammy message is not a false negative. 
The fact that a message is unwanted has nothing to do with DMARC.

> message to be blocked, there is no opportunity for recovery.

Actually, an opportunity of recovery exists.  The sender can have feedback 
mechanisms, such as 5yz SMTP replies, delivery notifications, return receipts 
or other web-based actions.  It can use feedback to recover from authentication 
errors.  Such errors happen in an apparent random fashion too.  For example, 
when the word "from" followed by a space appears in the beginning of a line, 
some agent insert a greater-than sign ('>') before it, thereby breaking a DKIM 
signature.  As soon as the sender recognizes that delivery failed, it can 
repeat sending the same message several times until, by chance, it gets a toss 
greater than its pct.  Phishers, OTOH, are known for not retrying.

The above is a use case for pct!= 0 and pct!=100.

> Therefore, false positives are a greater problem than false negatives, and
> the random guessing algorithm has the effect of replacing false negatives
> with false positives.

Replacing what...?

> For any single domain, incoming messages can be broken into three categories:
> 
> ·Legitimately-sourced messages which arrive with valid credentials.
> ·Legitimately-sourced messages which arrive with failed credentials.
> ·Impersonation messages which arrive with failed credentials.
> 
> receiver wants to accept all legitimately-sourced messages from the domain.   
> Since the sender is moving toward P=REJECT and the recipient wants to enforce 
> P=REJECT, we will also assume that mailing lists are not part of the mail stream.
> 
> messages.   This means that the denominator is unknown, but would be determined 
> by the volume of impersonation + legitimate messages.   The numerator for 
> computing wanted message rates (Q) is all of the legitimate messages.  The 
> numerator for computing unwanted message rates (P) is all of the impersonation 
> messages.
> 
> percentage of legitimate messages sent with imperfect credentials is irrelevant.

It is not irrelevant if the receiver rejects on DMARC fail.

> knowledge.    Can the evaluator benefit from that information?   I don’t think so.

Certainly not.  In the use case outlined above, the published pct can be a hint 
to the sender for the number of retries before resorting to something else.

> percentage of messages with correct credentials.    But any single evaluator 
> will need see the same weighted distribution of message sources.   It may not 
> receive any messages from non-compliant servers, it may receive messages only 
> from non-compliant servers, or any other possibly weight distribution.   
> Applying the source-domain’s percentage estimate to the received message stream 
> would only make sense if the weighting is comparable.

I don't think pct can be somehow calculated based on the percentage of failed 
authentications.  Even if one has the same percentage of failed authentication 
for every receiver, it still would make no sense to set pct at that value. 
What would a sender obtain?

> More importantly, the assumed goal for both sender and receiver is to have all 
> legitimately-sourced messages to be accepted.  Arbitrarily blocking some wanted 
> messages, for the sake of notifying about credentialling problems, works 
> against the goal of the evaluator and his user base.  It is too high a price to 
> pay.

It is still a percentage of the price you pay with pct=100.

> On Sun, Aug 1, 2021 at 5:13 AM Alessandro Vesely <[email-masked]> wrote:

I snip the original message.  Interested readers store the whole thread and it 
is in dmarc-ietf's archive anyway.

Best
Ale
--

---

From: Todd Herr <[email-masked]>
Date: Mon, 2 Aug 2021 15:49:12 -0400

On Sat, Jul 31, 2021 at 4:38 PM John Levine <[email-masked]> wrote:

> I'd make it a lot simpler:
>
>       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:

      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:* [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: Dotzero <[email-masked]>
Date: Mon, 2 Aug 2021 20:15:03 -0400

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

"6.7.4.  History of the "pct" Tag

   An earlier experimental version of the DMARC protocol [RFC7489]..."

RFC7489 is Informational, not experimental. In IETF nomenclature,
experimental status has a specific meaning.

Michael Hammer

---

From: "John Levine" <[email-masked]>
Date: 2 Aug 2021 22:10:05 -0400

OK except:

>   substance of reports generated, ...

Alter the reports?  Huh?  I was under the impression that the policy didn't
affect the reports, much less the pct.

R's,
John

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 2 Aug 2021 20:44:28 -0700

On Mon, Aug 2, 2021 at 12:49 PM Todd Herr <todd.herr=
[email-masked]> wrote:

> [...]

I suggest making this an appendix instead of leaving it up in the normative
area, with an appropriate forward reference.

And +1 to Michael's point about "experimental".

-MSK

---

From: Todd Herr <[email-masked]>
Date: Tue, 3 Aug 2021 08:08:18 -0400

> affect the reports, much less the pct.
My apologies...

My memory of the effect of the policy "p=quarantine; pct=0" vis-a-vis how
Google handles a domain's mail was faulty. I remember when working to
implement DMARC at $JOB[-1] for our corporate domain, I was seeing data in
the agg reports from Google when we were at p=none that led me to ask "WTF
are those hosts?" and digging around the various corners of the internet
unearthed the unknown at the time to me fix of "Yeah, you gotta be at
p=quarantine; pct=0" to get reports from Google that make sense.

There are several years old threads on mailop that speak to this topic,
with outsiders asserting that what is in fact happening is Google Groups is
rewriting the From when it's p=quarantine; pct=0, and Brandon Long from
Google in the thread doesn't challenge that assertion, so I'll remove
reference to the reporting alteration.

--

---

From: Barry Leiba <[email-masked]>
Date: Tue, 3 Aug 2021 08:21:47 -0400

The problem I have with leaving pct=0 in as the only (non-default) value is
that it locks history into the protocol.  It makes no sense to have a
binary situation specified by a tag called “pct” that is either 0 or 100.

If we’re leaving this in as a binary thing, (1) we’re already incompatible
with deployments that do pct=20 or whatever, so (2) we might better make it
a y/n or t/f valued tag for that function, deprecate pct entirely, and
leave text in a backward-compatibility section explaining what happened.

I just think that the pct= 0 or 100 thing won’t wear well and will appear
tattered quickly.

Barry

---

From: "John R Levine" <[email-masked]>
Date: 3 Aug 2021 11:52:22 -0400

> reference to the reporting alteration.

Makes sense, the reports are different because of the rewriting, not 
because the site that sees pct=0 is reporting differently.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Todd Herr <[email-masked]>
Date: Tue, 3 Aug 2021 15:54:58 -0400

On Tue, Aug 3, 2021 at 8:22 AM Barry Leiba <[email-masked]> wrote:

> The problem I have with leaving pct=0 in as the only (non-default) value
> is that it locks history into the protocol.  It makes no sense to have a
I don't disagree with you here, Barry, so let me propose this.

1. Eliminate the 'pct' tag entirely. Section 6.3, General Record Format,
says "unknown tags MUST be ignored." so we're covered on the compatibility
issue, I think.

2. Define a tag named "t", in a fashion somewhat similar to the t= tag
available for DKIM public key records, as follows:

   t:  DMARC policy test mode (plain-text; OPTIONAL; default is 'n').

      For the RFC5322.From domain to which the DMARC record applies, the

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

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

         rules it might have in place.  The domain owner is currently

         testing its specified DMARC assessment policy.

      n:  The default, a request to apply the policy as specified to any
         message that produces a DMARC "fail" result.

3. Include the following as an Appendix:

Appendix C.  History of the "pct" Tag

   An earlier informational version of the DMARC protocol [RFC7489]

   included a "pct" tag and specified all integers from 0 to 100

   inclusive as valid values for the 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".

   intended due to many factors, unless the value specified was either

   "0" or "100" (the default).  The default value was easily

   implemented, as it required no special processing on the part of the

   message receiver, while the value of "0" took on unintended

   significance as a value used by some intermediaries and mailbox

   providers as an indicator to deviate from standard handling of the

   message.

   These "custom" actions proved too valuable to the email community to

   remove their availability from this version of the protocol, but at

   the same time it didn't make sense to support a tag named "pct" that

   had only two valid values.  This version of the DMARC protocol

   therefore introduces the "t" tag as shorthand for "testing", with the

   valid values of "y" and "n", which should be analogous to the "pct"
   tag values "0" and "100", respectively.

--

---

From: Dave Crocker <[email-masked]>
Date: Tue, 3 Aug 2021 12:59:35 -0700

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

d/

-- 
Dave Crocker
[email-masked]
408.329.0791

Volunteer, Silicon Valley Chapter
Information & Planning Coordinator
American Red Cross
[email-masked]

---

From: Todd Herr <[email-masked]>
Date: Tue, 3 Aug 2021 16:42:07 -0400

> My question:  what does this accomplish, of significant benefit, that

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.

--

---

From: Dave Crocker <[email-masked]>
Date: Tue, 3 Aug 2021 14:08:09 -0700

On 8/3/2021 1:42 PM, Todd Herr wrote:
> 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:

I'm not trying to argue against your proposal or the one that preceded 
it, but am concerned that there be a pretty clear and strong case made 
for specific benefit.  That is, clarity about what the benefit will be 
and clarity that there is shared agreement that the benefit will be 
obtained and that it is substantial.

The pct style of mechanism is not typical for protocol standards, 
although it comes from a common system development background. And the 
fact that its use in DMARC is prompting significant change to that 
mechanism warrants additional care in justifying it and documenting it.  
IMO.

d/

-- 
Dave Crocker
[email-masked]
408.329.0791

---

From: David I <[email-masked]>
Date: Wed, 4 Aug 2021 08:20:03 +0000

This is the scenario we've seen across the UK public sector - at p=none, DMARC reporting showing lots of DMARC fails (SPF+DKIM failing) from IPs associated with an email service provider which both originates email and forwards it (commonly Google). At this stage you don't know if the failed messages are originated or forwarded and so if they will be lost at p=q/r, pct=100. When you switch to p=q,pct=0, forwarded messages are re-written, and so are not included in the DMARC reporting, and so if any failures remain, additional configuration associated with originating messages is required. If not, you're good to go from pct=0 to something stricter.

Benefit: Improve adoption of p=quarantine/reject by reducing the number of domain owners who to get stuck at p=none as they're unsure if switching to p=quarantine/reject will cause loss of legitimate email.

>From a 'getting people started with DMARC perspective', having p=none be 'safe' and not affect mail flows is attractive, and so having the behaviour change require an additional change is good. The fact that it's an opaque hack using p=q, pct=0 is a shame, and clarity of how you trigger this behaviour change in the document would be good.

HTH,
David

________________________________
From: dmarc <[email-masked]> on behalf of Dave Crocker <[email-masked]>
Sent: 03 August 2021 22:08
To: Todd Herr <todd.herr=[email-masked]>; IETF DMARC WG <[email-masked]>
Subject: Re: [dmarc-ietf] Some Proposed Language for a New pct Tag Defintion

On 8/3/2021 1:42 PM, Todd Herr wrote:
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:

I'm not trying to argue against your proposal or the one that preceded it, but am concerned that there be a pretty clear and strong case made for specific benefit.  That is, clarity about what the benefit will be and clarity that there is shared agreement that the benefit will be obtained and that it is substantial.

The pct style of mechanism is not typical for protocol standards, although it comes from a common system development background.  And the fact that its use in DMARC is prompting significant change to that mechanism warrants additional care in justifying it and documenting it.  IMO.

d/

--
Dave Crocker
[email-masked]<mailto:[email-masked]>
408.329.0791

Volunteer, Silicon Valley Chapter
Information & Planning Coordinator
American Red Cross
[email-masked]<mailto:[email-masked]>

This information is exempt under the Freedom of Information Act 2000 (FOIA) and may be exempt under other UK information legislation. Refer any FOIA queries to [email-masked]. All material is UK Crown Copyright ©

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 4 Aug 2021 11:03:08 +0200

On Mon 02/Aug/2021 21:49:12 +0200 Todd Herr wrote:
>>            avoid sending DMARC unaligned mail.

John's description of pct=0 is the most clear and concise I've seen so 
far.  Please use it.

> discusses the history of the pct tag and why the old values won't work any

Why won't the the old values work any longer?

>     remains the default, and "0".

Would you please expand on that operational experience?

I never published a pct, but I honor it when I see.  I posted[*] a 
list of old pct value I cached from various domains compared to their 
current values.  It shows that in most of the cases I saw, the 
evolution of pct= proceeds as envisaged in the original DMARC 
specification.  Is there evidence of the opposite?

IME pct works pretty well.  The argument that percentages don't have 
20 digits of precision on any finite number of messages is not a valid 
reason to deprecate it.

I described a possible use case for pct=80, earlier in this thread:

Assume a sender has some feedback mechanisms, such as 5yz SMTP 
replies, delivery notifications, return receipts or web-based actions. 
  This sender send transactional messages, but is concerned about 
authentication errors that happen in an apparent random fashion. 
Errors can depend on internal software or on external forwarders which 
unwittingly break DKIM signatures.  Relying on feedback, as soon as 
the sender recognizes that delivery failed, it repeats sending the 
same message several times until, by chance, it gets a toss greater 
than 80.

Phishers are known for not retrying, so setting pct=80 doesn't seem to 
compromise security.

I exemplified pct=80, but it can obviously start lower and be 
increased as mailing software gets better, eventually reaching the 
default.  Probably this scenario has been described before, and I 
don't understand why we are going to prohibit it.

Best
Ale
-- 

[*] 
https://mailarchive.ietf.org/arch/msg/dmarc/t-4Zv_DyEYzkSllT-wOAU1H1VK8

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 4 Aug 2021 11:32:15 +0200

>     intermediaries to have it affect my decision to move to a stronger

Examining the difference in the reports sounds hard, especially if the 
mail flows and remote operators' settings changed since p=none.  As a 
matter of fact, p=none lets a domain learn more about its mail flows, 
since aggregate reports contain DKIM and SPF identifiers of mediators.

Is that good to know?  Certainly, many operators prefer not to see any 
failure in the reports thy receive.  Hence p=quarantine; pct=0.  Is 
that /all/ operators, or are there any who would like to know about 
indirect mail flows anyway?

IOW: should we support an option to get aggregate reports even if a 
mediator munged From:?

Best
Ale
--

---

From: Todd Herr <[email-masked]>
Date: Wed, 4 Aug 2021 13:40:31 -0400

> since aggregate reports contain DKIM and SPF identifiers of mediators.

This is only true if the From: header is not munged. If it's munged to use
the domain of the intermediary, the originator will not see data about the
hop from the intermediary to the reporting destination in its aggregate
reports.

> IOW: should we support an option to get aggregate reports even if a
I submit that the option is already there...

Imagine the following path for a mail message:

    originator --------> From: munging intermediary -------------> final
destination

The "From: munging intermediary" has the ability to do DMARC validation on
messages received from the originator and to generate reports to the
originator by sending them to the address(es) specified in the rua tag of
the originator's sending domain DMARC record.

The "final destination", at the same time, has the ability to do DMARC
validation on messages received from the intermediary and to generate
reports to the intermediary, presuming that that intermediary publishes a
DMARC record for its munged sending domain.

--

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 5 Aug 2021 09:02:52 +0200

On Wed 04/Aug/2021 19:40:31 +0200 Todd Herr wrote:

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

If the final receiver sent such data to the originator, then the originator would see it.

> I submit that the option is already there...

Where?

>      originator --------> From: munging intermediary -------------> final destination
> 

I have the following on the top of the header of the message I'm replying to:

Return-Path: <[email-masked]>
Authentication-Results: wmail.tana.it;
   spf=pass smtp.mailfrom=ietf.org;
   dkim=pass reason="Original-From: transformed" header.d=valimail.com;
   dkim=pass (whitelisted) header.d=ietf.org
     header.b=TFOorAie;
   dkim=fail (signature verification failed, whitelisted) header.d=ietf.org
     header.b=mri3idDL
From: Todd Herr <[email-masked]>

During the night, the final destination's server sent an aggregate report to [email-masked].  Coincidentally, that's the same recipient who collects valimail.com's reports.  To be clear, the subject was /Report domain: dmarc.ietf.org Submitter: tana.it/.  I paste the relevant record after the tagline.  Undoing MLM transformation is just one way to unmunge.  Another possibility is ARC.  There might be more...

Whatever the technique, the final destination can try to unmunge, and that operation can succeed or fail.  The originator may be interested in the result.  For MLM transformation, how the originator signs messages is key for unmunging success, so having feedback would have a practical use.  Dunno about ARC, but maybe feedback is useful there too.  So it might seem a good idea to send reports to the originator as well.  If, instead, the originator prefers not to clutter aggregate reports with indirect mail flows results, then the final destination had better not to send it.  That decision could be made based on a header field, on a DMARC record tag, or both.

Best
Ale
-- 

	<record>
		<row>
			<source_ip>4.31.198.44</source_ip>
			<count>1</count>
			<policy_evaluated>
				<disposition>none</disposition>
				<dkim>pass</dkim>
				<spf>pass</spf>
				<reason>
					<type>mailing_list</type>
				</reason>
			</policy_evaluated>
		</row>
		<identifiers>
			<header_from>dmarc.ietf.org</header_from>
		</identifiers>
		<auth_results>
			<dkim>
				<domain>valimail.com</domain>
				<selector>google2048</selector>
				<result>pass</result>
				<human_result>through MLM transformation</human_result>
			</dkim>
			<dkim>
				<domain>ietf.org</domain>
				<selector>ietf1</selector>
				<result>pass</result>
			</dkim>
			<dkim>
				<domain>ietf.org</domain>
				<selector>ietf1</selector>
				<result>fail</result>
			</dkim>
			<spf>
				<domain>ietf.org</domain>
				<result>pass</result>
				<scope>mfrom</scope>
			</spf>
		</auth_results>
	</record>

---

From: Douglas Foster <[email-masked]>
Date: Thu, 5 Aug 2021 07:21:33 -0400

Alessandro writes in defense of PCT
   Assume a sender has some feedback mechanisms, such as 5yz SMTP
  replies, delivery notifications, return receipts or web-based actions.

  This sender sends transactional messages, but is concerned about

PCT could work IF evaluators are willing and able to send a Temporary Error
result (probably 451), instead of a permanent error, when
- a DMARC verification fails,
- the message is not unconditionally blocked or accepted on other criteria,
and
- the sender's PCT is between 1 and 99.
The result should include an extended status code in the 4.7.2x range.

This approach assumes that the temporary error status will cause the sender
to retry multiple times over an extended period.   Based on observed
configurations, this probably works out to at least 10 attempts.  In most
cases, the PCT formula will cause the message to be accepted after a delay,
which is a result equivalent to PCT=0.

Assuming that the message is wanted, the delay is likely to be noticed by
both sender and receiver, leading to communication between the parties and
corrective action which prevents a reoccurrence.

Assuming that the message is from a lazy spammer, the retries may not
happen, but the event can still appear in the logs (if evaluators track and
report the temporary errors).

Doug Foster

---

From: Todd Herr <[email-masked]>
Date: Thu, 5 Aug 2021 07:34:59 -0400

> If the final receiver sent such data to the originator, then the

Why or how could the final receiver send a report to the originator, though?

DMARC record lookup is based on the From: domain.

If the From: domain is munged so that it's now one that belongs to the
intermediary, there's no way to know what the originating domain was,
because there's no standard for munging.

Perhaps at a future date, if draft-vesely-dmarc-mlm-transform or similar
becomes a widely adopted and implemented standard, then receivers might be
able to easily send reports to originators. Remember though that MLMs are
only one special case of intermediary; auto-forwards, such as alumni.foo.edu
or even [email-masked] that just forwards everything to
[email-masked] are other cases that can cause authentication
failures and to the best of my knowledge there is no standard for header
munging for those cases, and frankly those hosts operating as
intermediaries in those flows may be less inclined to change their systems
than some MLMs have been. The IETF and you are perhaps outliers in regards
to the amount of effort expended to accommodate DMARC, and I applaud both
of your efforts, but I think we're a long way away from anything
approaching universal receivers reporting to every hop that handles a given
message.

--

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 5 Aug 2021 19:16:10 +0200

On Thu 05/Aug/2021 13:34:59 +0200 Todd Herr wrote:
>>>>> stronger assessment policy.
>>>>

MLM transformations are not meant to conceal it.

> able to easily send reports to originators.

Since munging is not a standard, I don't think unmunging could be. 
However, as we're granting citizenship to the former by describing 
pct=0, we could as well admit that the latter is possible.  Is it a 
desirable feature to restore the original From:?

Some say ARC will help overcoming From: rewrites.  How?  Certainly not 
because MLMs will stop rewriting all of a sudden.  If all what is 
wanted is to restore From:, it seems more likely that either the 
originator or the MLM will set up the header so as to allow doing so.

Now, it has been said, and perhaps will make its way to the spec, that 
p=quarantine; pct=0 will remove from reports the information about 
indirect mail flows.  Since we know that such information can be sent 
nevertheless, to ask how to deal with such cases is a legitimate question.

> Remember though that MLMs are only one special case of
> intermediary; auto-forwards, such as alumni.foo.edu or even
> [email-masked] that just forwards everything to 
> [email-masked] are other cases that can cause
> authentication failures and to the best of my knowledge there is no
> standard for header munging for those cases, and frankly those
> hosts operating as intermediaries in those flows may be less
> inclined to change their systems than some MLMs have been.

Forwarding without rewriting From: is a different problem.  It usually 
works, except for some cases that can be cured by strengthening 
signing practices.  Auto-conversions seem to have been eliminated 
already.  Further refinements to preserve DKIM signatures may be needed.

> The IETF and you are perhaps outliers in regards to the amount of
> effort expended to accommodate DMARC, and I applaud both of your
> efforts, but I think we're a long way away from anything 
> approaching universal receivers reporting to every hop that handles
> a given message.

Actually, reporting at every hop where just the recipient changes is 
the normal practice.

Best
Ale
--

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 6 Aug 2021 22:51:37 -0700

On Thu, Aug 5, 2021 at 4:22 AM Douglas Foster <
[email-masked]> wrote:

> PCT could work IF evaluators are willing and able to send a Temporary
> Error result (probably 451), instead of a permanent error, when
> - the message is not unconditionally blocked or accepted on other
> criteria, and
> This approach assumes that the temporary error status will cause the
> sender to retry multiple times over an extended period.
>

It should, since that's what the standard says ought to happen.  But then,
as was observed elsewhere in this thread, not all clients behave that way.

Based on observed configurations, this probably works out to at least 10
> attempts.  In most cases, the PCT formula will cause the message to be
> accepted after a delay, which is a result equivalent to PCT=0.
>

We usually use 4yz SMTP reply codes to mean there's some transient
condition preventing delivery; a later retry may yield a different result.
Random chance seems an awkward thing to shoe-horn into the notion of
"transient condition".

I think this could also DMARC skew statistics, as now any given message
could result in multiple distinct delivery attempts over a period usually
measured in days.  Care would have to be taken to identify and aggregate
the ones representing the same message.

-MSK

---

From: Douglas Foster <[email-masked]>
Date: Sat, 7 Aug 2021 14:49:34 -0400

This is essentially a form of greylisting.  I was deliberately proposing to
not track repeats, to avoid the problems that greylisting encounters from
source domains with many servers.   Since greylisting is common, I did not
expect pushback on the propriety of the approach.  What codes are currently
used by systems that implement greylisting?

Changing the PCT disposition from Reject to Defer causes a dramatic change
in my perception of the algorithm.  I am as much enthused about this
approach as I was resistant to the old one.

I thought the DMARC implementation consulants and mailing list operators
would be equally intrigued, so I have been surprised by the silence this
week.

I can envision some domain owners going to PCT=99 and stoping there
permanently.  As an evaluator, I would rather have that than p=None

Doug