On Sun, Sep 10, 2023 at 11:34 AM Scott Kitterman <[email protected]> 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
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
