Subject: [dmarc-ietf] I-D Action: draft-ietf-dmarc-dmarcbis-03.txt

From: [email-masked]
Date: Wed, 18 Aug 2021 13:12:08 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Domain-based Message Authentication, Reporting & Conformance WG of the IETF.

        Title           : Domain-based Message Authentication, Reporting, and Conformance (DMARC)
        Authors         : Todd M. Herr
                          John Levine
	Filename        : draft-ietf-dmarc-dmarcbis-03.txt
	Pages           : 67
	Date            : 2021-08-18

Abstract:
   This document describes the Domain-based Message Authentication,
   Reporting, and Conformance (DMARC) protocol.

   DMARC permits the owner of an email author's domain name to enable
   verification of the domain's use, to indicate the Domain Owner's or
   Public Suffix Operator's severity of concern regarding failed
   verification, and to request reports about use of the domain name.
   Mail receiving organizations can use this information when evaluating
   handling choices for incoming mail.

   This document obsoletes RFC 7489.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dmarc-dmarcbis/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-dmarc-dmarcbis-03.html

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dmarc-dmarcbis-03

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Todd Herr <[email-masked]>
Date: Wed, 18 Aug 2021 16:17:57 -0400

Greetings.

The main update in this draft is removal of the "pct" tag, with an
explanation as to why, and an introduction of the "t" tag in an effort to
maintain the functionality provided today by "pct=0" and "pct=100".

The rest is just some wordsmithing, shuffling text around, and trying to
introduce tables in a couple of locations to replace what I thought was
messy text.

On Wed, Aug 18, 2021 at 4:12 PM <[email-masked]> wrote:

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

-- 

*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: Alessandro Vesely <[email-masked]>
Date: Thu, 19 Aug 2021 13:18:45 +0200

On Wed 18/Aug/2021 22:17:57 +0200 Todd Herr wrote:
> explanation as to why, and an introduction of the "t" tag in an effort 
> to maintain the functionality provided today by "pct=0" and "pct=100".

As held earlier, I disagree with such gratuitous breaking of the 
existing installed base and published records.

It goes without saying that domains who are publishing pct=0 will 
slowly adapt by adding t=y and never removing pct.  Those who publish 
pct=50 and are satisfied with it will have to give up, despite their 
own operational experience.

In any case, I object to the use of the Probability Mass Function as 
applied to Binomial Distributions argument.  It presumes that the 
percentage in question refers to the number of messages sent during a 
given day, which was never specified.  The spec said "Percentage of 
messages from the Domain Owner's *mail stream*".  The random function 
applied to such stream is equivalent to computing a Monte Carlo 
integration on a finite set.  Since *all samples* are eventually 
considered, the result tends to the exact value.

Best
Ale
--

---

From: Todd Herr <[email-masked]>
Date: Thu, 19 Aug 2021 08:52:41 -0400

> existing installed base and published records.

I disagree with your characterization of removal of the "pct" tag as
"gratuitous breaking"; the spec has long contained the following text:

Only tags defined in this document or in later extensions, and thus added
to that registry,
are to be processed; unknown tags MUST be ignored.

and so should a DMARC protocol without the "pct" tag be formally adopted,
there should be no breaking of any existing DMARC implementations.

> considered, the result tends to the exact value.

I will continue to contend that the first sentence of the existing
definition of the "pct" tag was incorrectly worded. It reads:

Percentage of messages from the Domain Owner's mail stream to which
the DMARC policy is to be applied.

and as I've written in other threads, such phrasing makes no sense to me,
because a DMARC policy cannot be applied to a message which passes DMARC
verification checks.

I believe my argument to be supported by the existing definitions of
"quarantine" and "reject", which read in part:

      quarantine:  The Domain Owner wishes to have email that fails
the DMARC mechanism check be treated by Mail Receivers as suspicious.

      reject:  The Domain Owner wishes for Mail Receivers to reject
email that fails the DMARC mechanism check.

There is nothing in the text there that talks of applying a policy of
"quarantine" or "reject" to messages that pass the DMARC mechanism check,
so it follows for me that the "pct" tag was never intended to apply to the
entire mail stream, only to those messages that failed the check. Given my
assertion here, I believe that the Probability Mass Function as applied to
Binomial Distributions is the correct argument to make against the pct tag,
and I was rather pleased with myself in how I described it in an earlier
revision of the spec:

         if (random mod 100) < pct then

            selected = true

         else

            selected = false

   The pseudocode shown above is an example of that approximation,

   relying on a random number generator to effectively produce a whole

   number between 0 and 99, inclusive.  If that number is less than the

   value of the "pct" tag, then a message producing a DMARC "fail"

   result will be subject to the DMARC policy in question; if not, it

   will be subject to the lesser policy.  Over time and given enough

   iterations of the pseudocode, this should produce a roughly uniform

   distribution of all values across the range, which we will refer to

   going forward as "the pool".  However, mathematics teaches us that

   the pool cannot be guaranteed to produce the desired result.

   The sampling done to honor the "pct" tag is known in mathematics as a

   Binomial Distribution, where a number of independent samples of the

   pool are taken, with each one having the same probability of

   producing a number that is less than the value of the "pct" tag.  A

   Binomial Distribution is expressed by the following function, known

   as a probability mass function (PMF):

                 n!         x          n-x

     f(x) = ----------- *  p  * (1 - p)

            (n-x)! * x!

   In English, the PMF is a way to calculate the probability that x

   items from a sample of n items will have the desired result when p is

   the probability that any one item will have the desired result.

   For example, for a DMARC policy record with pct=20, we let p = 0.2,

   and to calculate the probability that 1 out of every 5 messages will

   be assigned the requested policy, we have:

           5!           1            5-1

      ----------- *  0.2  * (1 - 0.2)     =

      (5-1)! * 1!

         120       1     4

        ----- * 0.2 * 0.8  = 5 * 0.2 * 0.4096 = 0.4096

         24

        0.4096 * 100 = 40.96%

   The above demonstrates that for every five messages producing a DMARC

   "fail" result, there is a slightly less than 41% chance that just one

   of the five will have the requested policy applied to it.  The table

   below shows the percent probability for all possible results:

        -----------------------------------

        | X  | Percent chance that X of 5 |

        |    |  will have policy applied  |

        -----------------------------------

        | 0  |        32.768%             |

        -----------------------------------

        | 1  |        40.96%              |

        -----------------------------------

        | 2  |        20.48%              |

        -----------------------------------

        | 3  |         5.12%              |

        -----------------------------------

        | 4  |         0.64%              |

        -----------------------------------

        | 5  |         < 0.1%             |

        -----------------------------------

Your mileage may vary, of course, but the larger point here is that while
you personally have objected to removal of the "pct" tag, there has
seemingly been rough consensus supporting the idea of removing all values
except 0 and 100, and quite a lot of agreement that having a tag named
"pct" that only had valid values of 0 and 100 didn't make sense, so this
rev is a first attempt to find a path to documenting something that does
make sense, given that there is support for keeping the functionality that
pct=0 provides.

--

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 19 Aug 2021 20:36:08 +0200

On Thu 19/Aug/2021 14:52:41 +0200 Todd Herr wrote:
> Only tags defined in this document or in later extensions, and thus
> added to that registry, are to be processed; unknown tags MUST be
> ignored. >

Excuse me, but I don't get it.  An existing DMARC implementation which 
treats pct=, should a DMARC protocol without it be formally adopted, 
MUST be rewritten, re-tested, re-installed.  IOW, the current 
installation is broken.

As for existing records, they have to work with the updated 
implementations as well as with the ones now formally broken.

>     Percentage of messages from the Domain Owner's mail stream to
>     which the DMARC policy is to be applied.
> 
>     quarantine:  The Domain Owner wishes to have email that fails the
>     DMARC mechanism check be treated by Mail Receivers as suspicious.
> 
> entire mail stream, only to those messages that failed the check.

Agreed.  The language of RFC 7489 seems to talk about applying the 
DMARC check and then applying the policy if the check fails.  This in 
no way limits the mail stream to a single day.

> Given my
>     will be subject to the lesser policy.

Correct.

>     Over time and given enough
>     going forward as "the pool".

This definition of "the pool" is not in the spec.  It is enough to 
have a decent random function.  Anyway...

>     However, mathematics teaches us that
>     producing a number that is less than the value of the "pct" tag.

Here you deviate from the spec.  A binomial distribution is 
characterized by a fixed number of samples n and a probability pct. 
The spec only talks about the probability pct.  Your argument seems to 
assume that a mail stream is made of 5 messages or less, which is 
completely nonsensical w.r.t. to common understanding of DMARC usage.

Indeed, most servers end up relaying more than five messages to any 
receiver within a given mail stream.

Now, I confess that I don't have a formal definition of mail stream at 
hand.  I tend to consider a stream, for example, the series of 
messages signed with a given DKIM selector, or emitted by a given 
relay.  Roughly, a mail stream is the entity that a reputation tracker 
attaches a value to, isn't it?

>     A Binomial Distribution is expressed by the following function, known

The spec does not say that pct=20 requires a receiver to not applying 
the policy in one message out of the first five ones.  My 
understanding is that it says that /on average/ a receiver will not 
apply the policy in the 20% of the failed messages of the whole mail 
stream.

>          |    |  will have policy applied  | >          -----------------------------------
>          | 0  |        32.768%             |

Whatever the definition of stream, the binomial distribution is not 
the right tool to compute what's happening with realistic numbers. 
Now it's about dinner time and I'm not willing to program a binary 
distribution for a decently high number of trials.  What would you 
reckon it is the probability that, out of 1000 failed messages, the 
percent chance probability of applying the policy to X message is such 
that 150 < X < 250?  That would be an inefficient way to compute the 
precision of Monte Carlo approximation.

> make sense, given that there is support for keeping the functionality that

I agree pct with only valid values of 0 and 100 makes no sense.

Best
Ale
--

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 19 Aug 2021 12:21:43 -0700

> there should be no breaking of any existing DMARC implementations.

Not expressing an opinion on the new text, but just on this point:

I agree the parsers won't break from this change, but an operator currently
advertising "pct=33" will suddenly stop getting what it thought it was
asking for.  One could argue that this constitutes "breakage".

-MSK, participating

---

From: Todd Herr <[email-masked]>
Date: Thu, 19 Aug 2021 15:37:06 -0400

On Thu, Aug 19, 2021 at 3:22 PM Murray S. Kucherawy <[email-masked]>
wrote:

>
> I agree the parsers won't break from this change, but an operator
> currently advertising "pct=33" will suddenly stop getting what it thought
> it was asking for.  One could argue that this constitutes "breakage".
>
>
It has been argued by some that an operator currently advertising "pct=33"
(or anything other than 0 or 100) was never getting what it thought it was
asking for in the first place, hence the discussion about removing the pct
tag.

--

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 20 Aug 2021 10:42:04 +0200

On Thu 19/Aug/2021 21:37:06 +0200 Todd Herr wrote:
> On Thu, Aug 19, 2021 at 3:22 PM Murray S. Kucherawy wrote:
> 

Argued by some is not the same as rough consensus.

Best
Ale
--

---

From: Douglas Foster <[email-masked]>
Date: Fri, 20 Aug 2021 06:18:37 -0400

On the subject of PCT, we did not reach agreement, we reached silence.
 Silence comes across as a move by the majority to silence dissenters.
 The chairs are empowered to decide whether this is an appropriate tactic
by the majority, and whether a majority or supermajority is a sufficient
approximation of consensus.

I believe that PCT is a weak solution to a real problem, and that
eliminating PCT makes the problem much worse.    This situation will
operate against the interests of all legitimate participants.    PCT needs
to be improved, not discarded.   There is a lot to talk about here.

Doug Foster

---

From: Barry Leiba <[email-masked]>
Date: Fri, 20 Aug 2021 09:34:19 -0400

There is a difference between silencing dissenters and saying that the
dissent has been discussed and the rough consensus disagrees with the
dissenters.  Everyone needs to understand when they've lost an
argument -- not because people are against them, but simply because
reasonable people disagree, and we need to make a rough-consensus
decision -- and move on.

In this case, my reading of the discussion is that (1) there are good
arguments and plenty of evidence that PCT isn't working consistently
and interoperably, that PCT is mostly not necessary in a Proposed
Standard (as opposed to Experimental or Informational) version of
DMARC, and that the main use case that has been raised for retaining
it is a binary, on/off situation.  I believe the working group has
*rough* consensus on that, recognizing that agreement on it is not
unanimous.

There is a *proposal* for handling the binary situation differently.
I believe the working group as a whole has expressed interest in that
proposed solution, though we do not yet have rough consensus on the
details and text of that.

Barry, as chair

On Fri, Aug 20, 2021 at 6:19 AM Douglas Foster
<[email-masked]> wrote:
>
> On the subject of PCT, we did not reach agreement, we reached silence.   Silence comes across as a move by the majority to silence dissenters.   The chairs are empowered to decide whether this is an appropriate tactic by the majority, and whether a majority or supermajority is a sufficient approximation of consensus.
>
> I believe that PCT is a weak solution to a real problem, and that eliminating PCT makes the problem much worse.    This situation will operate against the interests of all legitimate participants.    PCT needs to be improved, not discarded.   There is a lot to talk about here.
>
> Doug Foster
>
>
>
>

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 20 Aug 2021 20:34:21 +0200

On Thu 19/Aug/2021 20:36:08 +0200 Alessandro Vesely wrote:
> distribution for a decently high number of trials.

Today I took the time to compute it.  Consider the values of k that 
are acceptable up to a rounding error.  That is, for pct=20 and n = 10 
we have k = 1, 2.  Both values of k approximate the expected 
percentage, so we consider their sum as the probability that the 
result of applying the specified algorithm is acceptable.  As n grows, 
so grow the acceptable k's.  The results are as follows:

      n | low k | high k | probability that the result of applying
        |       |        | the specified algorithm is acceptable
-------+-------+--------+-------------------------------------
     10 |     1 |      2 | 0.570425
    100 |    15 |     24 | 0.788203
   1000 |   150 |    249 | 0.999913
  10000 |  1500 |   2499 | 1.000000

That proves that as the number of failed DMARC checks raises, the 
specified algorithm tends to deliver the exact result.

I attach a program to compute those figures in case anyone likes to 
review its correctness.

Best
Ale
--