Re: [dmarc-ietf] Some Gmail comments on DMARCbis version 28

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.net@dmarc.ietf.org <mailto:hsantos=40isdg.net@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.com@dmarc.ietf.org> wrote:
> 
> 
> 
> On Sun, Sep 10, 2023 at 11:34 AM Scott Kitterman <sklist@kitterman.com <mailto:sklist@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