My overall assessment as an early adopter and implementation: <implementator.review>
DMARC SHOULD NOT be declared a Standard Track document. We still have the potential to develop a sound 1st, 3rd party DKIM Policy model. Declaring DMARCBis a STD will only hamper future development. Keep it experimental or informational. DMARC/Bis has represented a big IETF “Elephant In The Room” change in allowing External 3rd Party Organizations to put barriers of entry to correct the IETF protocol development.. Change is needed. DMARCBis is not it. Is there is an Update Document minus the subjectives considerations. It has been a fair process but a very high hurdle to correct a serious IETF protocol problem. </implementator.review> All the best, Hector Santos > On Apr 4, 2024, at 4:47 PM, Jim Fenton <fen...@bluepopcorn.net> wrote: > > 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
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
