Re: [dmarc-ietf] Some Gmail comments on DMARCbis version 28

[Douglas Foster <[e-mail]>]

I objected strongly to the RFC 7489 language which provides disposition
instructions based on the PCT clause, and still do.
A brief review:
There are many percentages mixed up together in this issue:

   - The percentage of domain message sources which provide proper
   authentication at origination.
   - The percentage of domain messages which originate with proper
   authentication.   This is determined by the volume distribution between
   sources, which is likely to be variable.
   - The  percentage of domain messages which are received with
   authentication.   This will be different for each evaluator, depending on
   the sources from which those messages originate.  This is also affected by
   transit issues.

But none of those percentages actually matter.   The one that matters to
the evaluator is:

   - The conditional probability that an unauthenticated message is
   actually from the domain and not from an impersonator.   For this test, the
   denominator depends on the volume of impersonation messages, which is
   completely independent of the domain's message volumes.

And finally, even if this last percentage could be determined, the advice
is wrong.   If this percentage is the determining factor for allow or
block, the error-minimizing strategy is to either accept all, if the
legitimate percentage is high, or block all, if the legitimate percentage
is low.   The boundary between the two strategies depends on the relative
weight given to allow errors and block errors.   If the weighting is equal,
the breakpoint is 50%.

In RFC 7489, we have a domain-provided percentage whose calculation is left
undefined.   Whatever the calculation, the result has little relevance to
the evaluator's risk assessment.   It is actually harmful to advise
evaluators to disposition using the sender's percentage and a random number
generator.

The WG observed that some forwarders and some evaluators behave differently
between "p=none pct=100" and "p=quarantine pct=0".  The "t=" clause was
introduced to provide that distinction.

I don't object to leaving the PCT clause in place as a historical relic,
but we should repudiate the idea that the evaluator obtains
valuable guidance from it.

Doug Foster


On Fri, Sep 8, 2023 at 7:46 AM Alessandro Vesely <[e-mail]> wrote:

> On Thu 07/Sep/2023 18:28:59 +0200 Wei Chuang wrote:
> >
> > Regarding the languages in section 8.6 "It is therefore critical that
> domains
> > that host users who might post messages to mailing lists SHOULD NOT
> publish
> > p=reject.  Domains that choose to publish p=reject SHOULD implement
> policies
> > that their users not post to Internet mailing lists", we wanted to point
> out
> > that this is impossible to implement.  Many enterprises already have
> "p=reject"
> > policies.  Presumably those domains were subject to some sort of
> spoofing which
> > is why they went to such a strict policy.  It would be unreasonable to
> tell
> > them to stop posting to mailing lists as many likely already use mailing
> list
> > services and will want to continue to use them.  The one thing that
> makes this
> > tractable is the SHOULD language as we may choose not to not follow this
> aspect
> > of the specification.  Our suggestion is that there is not a lot of
> value in
> > including this language in the bis document if the likely outcome is
> that it
> > will be ignored, and rather more effort should be placed with a
> technical
> > solution for interop with mailing lists.
>
>
> There is an "until the authentication ecosystem becomes more mature and
> deliverability issues are better resolved."  Some sites may consider that
> the
> mailing lists in their particular niche already solved the problem.  The
> (temporary?) alternative is to use different domains, at the cost of
> reviewing
> all subscriptions...
>
>
> > We question the benefit versus the implementation effort and confusion
> of
> > deprecating the DMARC policy "pct" percentage mode and replacing it with
> "t"
> > test.  We do agree that there is benefit in having receivers support a
> debug
> > mode to enable DMARC deployment and that the test mode supports the most
> useful
> > use case for testing with indirect mailflow behavior.   However "pct"
> > represents a sunk cost and implementing test mode seems redundant to the
> > already existing "pct" percentage mode.  Moreover both modes will likely
> need
> > to be supported for a while.  We do see senders use "pct" ratcheting and
> it
> > will be confusing to them when at some point they will have to switch.
>
>
> +1,  there are sites actually using pct=, however few.  I appeal to the WG
> to
> reconsider this decision.  Removing it is a gratuitous incompatibility.
>
>
> Best
> Ale
> --
>
>
>
>
>
> _______________________________________________
> dmarc mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dmarc
>