Re: [dmarc-ietf] 5322.From Header Rewrite specification

[John Levine]

It appears that Todd Herr   said:
>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
>.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).

This is my rewrite hack which approximately nobody does. I do it on my
handful of lists, the IETF does with custom code, and commercial
LISTSERV has an option to rewrite the address into @list.domain.
To do so, the list software has to be able to futz with the
configuration of the underlying MTA to manage the forwarding, and
places running list software like Mailman and Sympa on top of postfix
can't do that. (I think LISTSERV has a built in MTA but it is quite
expensive.)

What it does *not* say is to put the list address in the From header
which is the ugly hack that list software has resorted to.  See endless
prior discussions of why that makes lists worse.

Barry is right. If you don't care about interoperability, you can and
will do whatever you want, but if you do, you don't set a DMARC policy
on domains that send mail from people.

R's,
John

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] 5322.From Header Rewrite specification

[Scott Kitterman]

On March 31, 2023 6:50:22 PM UTC, Todd Herr 
 wrote:
>On Fri, Mar 31, 2023 at 2:32 PM Hector Santos 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
>.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 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

Re: [dmarc-ietf] 5322.From Header Rewrite specification

[Todd Herr]

On Fri, Mar 31, 2023 at 2:32 PM Hector Santos  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
.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  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

-- 

*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-ietf] 5322.From Header Rewrite specification

[Hector Santos]

Is there a specification for rewriting the 5322.From to help resolve DMARC 
p=reject redistribution problems?

What is the logic the IETF.ORG  list using?

Thanks in advance

—
HLS___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc