Re: [dmarc-ietf] There is no pony, Overall last-call comments on DMARC
My overall assessment as an early adopter and implementation: 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. All the best, Hector Santos > On Apr 4, 2024, at 4:47 PM, Jim Fenton 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
Re: [dmarc-ietf] There is no pony, Overall last-call comments on DMARC
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. It was totally obvious at the time what DKIM was intended for, so I don't think that's likely to be persuasive. In practice, ARC isn't that bad. IF you're a really big mail system you can collect your own repuations, if you're not so big your users probably subscribe to few enough legit ARC signers that you can manually whitelist them. On my system I think there's about five. It's not like the general spam problem where you have a zillion new identifiers every day most of which are spam but a few are not. 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. Well, ADSP actually was bad, and DMARC has reinvented much of what was bad about it, but unlike ADSP, it's used by every significant mail system in the world so we're stuck with it. I have heard somewhere that successful standards document actual practice even if the practice is not ideal. It's up to us, we can say nope, not a standard, and people will use it as a standard, or we can say it's not great but here's the standard, and they will use it as a standard. I know which one I'd do. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] There is no pony, Overall last-call comments on DMARC
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
Re: [dmarc-ietf] There is no pony, Overall last-call comments on DMARC
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. 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. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
