On March 31, 2023 6:50:22 PM UTC, Todd Herr <todd.herr=40valimail....@dmarc.ietf.org> wrote: >On Fri, Mar 31, 2023 at 2:32 PM Hector Santos <hsantos= >40isdg....@dmarc.ietf.org> wrote: > >> Is there a specification for rewriting the 5322.From to help resolve DMARC >> p=reject redistribution problems? >> > >RFC 7960 isn't a specification for rewriting 5322.From per se, but section >4.1.3.1 discusses the topic of rewriting that header, including this text: > > Another option for ReSenders is to rewrite the RFC5322 ><https://www.rfc-editor.org/rfc/rfc5322>.From header > field address to a locally controlled address that will be forwarded > back to the original sender (subject to its own ReSender forwarding > mitigations). > > >https://www.rfc-editor.org/rfc/rfc7960.html#section-4.1.3.1 > > >> What is the logic the IETF.ORG list using? >> >> >I'm guessing it's: > >if (DMARC policy of poster's email domain exists and is not p=none) then > >rewrite 5322.From to >orginallocalpartasciihex40originaldom...@listname.ietf.org > >fi > >For example: > >$ host -tTXT _dmarc.isdg.net > >_dmarc.isdg.net descriptive text "v=DMARC1; p=reject; atps=y; rua=mailto: >dmarc-...@isdg.net; ruf=mailto:dmarc-...@isdg.net;"; > > >Leads to: > >On Fri, Mar 31, 2023 at 2:32 PM Hector Santos <hsantos= >40isdg....@dmarc.ietf.org> wrote: > > >The rewriting that the IETF is doing seems to be from the same neighborhood >as the Sender Rewriting Scheme used sometimes for 5321.From rewriting to >mitigate SPF failures - https://www.libsrs2.org/srs/srs.pdf
Not at all. Mail From is a protocol level identity intended to be consumed by machines. A non-technical user should never see one. The 5322.From is intended to be consumed by humans (and machines), so I think the comparison is inapt. Scott K _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
