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