On 4 Apr 2024, at 13:31, John R. Levine wrote: >> I don’t think it’s scope creep at all. The WG charter puts “Review and >> refinement of the DMARC specification” in phase III, after “Specification of >> DMARC improvements to support indirect mail flows”. It seems clear to me >> that standards-track DMARC needs to incorporate those improvements. >> >> IESG accepted ARC as an improvement to support indirect mail flows, and I >> think a complete solution needs to incorporate that. I wish there were >> better data to support advancing ARC to standards track, and not just from >> Google (it has to work for smaller players as well). >> >> But I am troubled by the possibility that ARC might require domain >> reputation to avoid ARC header fields supporting From address spoofing. One >> reason it might work for Google is because they’re big enough to derive >> their own domain reputation. We’ve not had success with domain reputation at >> internet scale. > > No might about it -- ARC is only useful with domain reputation. Of course, > DKIM is only useful with domain reputation, as were Domainkeys and IIM, so I > don't see why it's a problem now.
Much of the objective of DomainKeys/IIM/DKIM was to provide a reliable domain identifier that could be used by a reputation system. They avoided saying that they were doing anything about spam and phishing. OTOH, DMARC is explicitly saying that it’s there to do something about phishing. > We've been going around and around for years now. DMARC works pretty well > for direct mail flows, so-so for simple indirect flows (forwarders) and > really badly for mediated indirect flows (mailing lists.) There is nothing > better than ARC to mitigate those problems and this WG certainly isn't going > to invent anything now. I agree that at this point we don't have enough > evidence to advance ARC, so we can punt the question of what or when to do > with it to MAILMAINT or something. > > Our choices are to say here's what DMARC does, it has these problems, here's > how to use it for the situations where it works, here's how to sort of > mitigate the ones where it doesn't. Or we can stamp our feet and say DMARC > is BAD and we will not endorse it and NOBODY should use it, and the rest of > the mail world will say isn't that cute, the IETF is having a tantrum. Or we can say that it’s not ready for standards track yet. The only time I can think of in this space that we have stamped our feet and said something is BAD was with ADSP. But I am troubled by the mandatory requirements imposed by organizations citing an informational RFC, RFC 7489. It makes it seem like standards track doesn’t mean as much as it should. -Jim _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
