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= 40valimail....@dmarc.ietf.org> 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... > > -- > > *Todd Herr* | Technical Director, Standards and Ecosystem > *e:* todd.h...@valimail.com > *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. > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc >
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
