I have been “militantly” against Authorship destruction. But fast forward to today, I am willing to support it IFF it can be officially sanctioned by the IETF using a well-defined Rewrite protocol for List Systems.
Overall, I believe if the middle ware performs a rewrite due to an author’s restrictive policy, we should consider these technical concepts: 1) Applicable to p=reject or p=quarantine only, 2) A domain rewrite SHOULD match the original domain security. For example, for this list, the IETF list manager rewrites my address: hsantos@isdg,net to hsantos=40isdg....@dmarc.ietf.org <mailto:hsantos=40isdg....@dmarc.ietf.org> I believe any domain transformation should retain the p=reject isdg.net <http://isdg.net/> policy security level. In this case, p=reject was weaken to p=none with the domain change. So I can support rewrites iff the domain security can be retained. All the best, Hector Santos > On Sep 14, 2023, at 5:27 PM, Wei Chuang <weihaw=40google....@dmarc.ietf.org> > wrote: > > > > On Sun, Sep 10, 2023 at 11:34 AM Scott Kitterman <skl...@kitterman.com > <mailto:skl...@kitterman.com>> wrote: >> On Thursday, September 7, 2023 12:28:59 PM EDT Wei Chuang wrote: >> > We had an opportunity to further review the DMARCbis changes more broadly >> > within Gmail. While we don't see any blockers in the language in DMARCbis >> > version 28 >> > <https://datatracker.ietf.org/doc/html/draft-ietf-dmarc-dmarcbis-28> and >> > can live with what is there, we wanted to briefly raise some concerns >> > around some of the changes. Two points. >> > >> > Regarding the languages in section 8.6 "It is therefore critical that >> > domains that host users who might post messages to mailing lists SHOULD NOT >> > publish p=reject. Domains that choose to publish p=reject SHOULD implement >> > policies that their users not post to Internet mailing lists", we wanted to >> > point out that this is impossible to implement. Many enterprises already >> > have "p=reject" policies. Presumably those domains were subject to some >> > sort of spoofing which is why they went to such a strict policy. It would >> > be unreasonable to tell them to stop posting to mailing lists as many >> > likely already use mailing list services and will want to continue to use >> > them. The one thing that makes this tractable is the SHOULD language as we >> > may choose not to not follow this aspect of the specification. Our >> > suggestion is that there is not a lot of value in including this language >> > in the bis document if the likely outcome is that it will be ignored, and >> > rather more effort should be placed with a technical solution for interop >> > with mailing lists. >> >> It might be helpful if you could describe this technical solution from your >> perspective. >> >> If there were a reasonable technical solution available, I think this would >> be >> a much easier change to support (in my opinion, and a believe a substantial >> number of others, rewriting From is not a reasonable technical solution). >> >> Scott K > > Apologies for the delay in getting back to this. > > So yes I believe there are two possible technical approaches broadly speaking > 1) Support rewriting From and being able to reverse it along with message > modifications to recover the original DKIM message hash to validate the > original DKIM signature. 2) Create a new message authentication method that > is tolerant of message modifications and message forwarding, and supported by > DMARC. From header rewriting would not be necessary in this scenario. > Beyond the complexity of supporting either method, another tricky thing in > both cases is supporting an ecosystem with diverse adoption of said > technique. More concrete proposals for 1) and 2) are 1) > draft-chuang-mailing-list-modifications > <https://datatracker.ietf.org/doc/draft-chuang-mailing-list-modifications/> > and 2) draft-chuang-replay-resistant-arc > <http://draft-chuang-replay-resistant-arc/>. And there are other I-Ds out > there particularly for the first approach. > > -Wei > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org <mailto:dmarc@ietf.org> > https://www.ietf.org/mailman/listinfo/dmarc
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
