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

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 <vesely@tana.it> wrote:

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