On Thursday, September 14, 2023 5:27:08 PM EDT Wei Chuang wrote: > On Sun, Sep 10, 2023 at 11:34 AM Scott Kitterman <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. And there are other I-Ds out > there particularly for the first approach. > > -Wei
Thanks. That's helpful. I interpret that as confirming my view that there is not currently a reasonable technical solution available. While these may be promising for the future, it's not like any of those solutions are things that are currently available to email list administrators. I don't think any of those things are going to mature quickly, so I would find it concerning to delay publication of DMARCbis until they are ready. If we aren't going to put DMARCbis on ice for a few years (please, let's not), then I think we're left with something like the language that's there now or some variation of NOT RECOMMENDED unless [unobtainium] which amounts to the same thing, but is in my view less clear. I think in a couple of years we could do some kind of an update that relaxes the current language based on one of these techniques if they become deployable, but I don't think we can do it now. Scott K _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
