> On Apr 22, 2023, at 4:53 PM, Dotzero <dotz...@gmail.com> wrote: > > On Sat, Apr 22, 2023 at 2:04 PM Hector Santos > <hsantos=40isdg....@dmarc.ietf.org <mailto:40isdg....@dmarc.ietf.org>> wrote: >> >>> On Apr 22, 2023, at 12:58 PM, John Levine <jo...@taugh.com >>> <mailto:jo...@taugh.com>> wrote: >>> >>> It appears that Jesse Thompson <z...@fastmail.com >>> <mailto:z...@fastmail.com>> said: >>>> -=-=-=-=-=- >>>> >>>> A DNS-based lookup, perhaps in the style of ATSP as this thread is >>>> describing, to query for not just domain-level authorization, but also >>>> potentially user-level authorization, I think is >>>> compelling because it can: >>> >>> Once again, no. This is not mission creep, it is mission gallop. >> >> The current mission is chaos!! I sometimes wonder If the intent is to keep >> it chaotic to show non-consensus in really the strategy. Jesse was >> referring to user policies. ATPS is about domain policies. Lets not >> confuse this. >> >>> Nobody uses ATSP, nobody is going to use ATSP, this is just yet more >>> distraction and wheel spinning that is keeping us from finishing. >> >> -1 >> >> First, not true, there is running code using ATPS, and you know it. Second, >> there are APIs that support it. It may be disabled in the open source but >> it's there. Second, when an editor does not champion his own work, it will >> be much harder to sell. There is absolute no reason why a receiver can not >> to an ATPS check if its already doing an DMARC with false positive results >> due to not doing an ATPS.-- >> >> What has kept us from finishing this 17+ year project was the editor of ADSP >> and now editor of DMARCbis preventing 3rd party authorization concepts. He >> removed it from SSP when it was hijacked with ADSP. To his credit, its on >> the record, he didn’t want people using ADSP and was successful to get it >> abandoned as a proposed standard and made it historic. > > You are incorrect that SSP was "hijacked" by ADSP. I was the one who > suggested the change from Sender Signing Protocol to Author Domain Signing > Protocol because the effort was about domains and NOT individuals. It was > ONLY a name change. As with many other efforts there was evolution, both > before the name change (which occurred around SSP 11 if I remember correctly) > and after. Anyone can go back to the list archives to verify this.
I welcome reviews, the facts. In fact, I labeled it a "Poison Pill” as there was no way it can pass as Proposed Standard. And I was right. I wrote about it in my 2008 blog when introduced as ASP. https://santronics.blogspot.com/2008/02/poison-pills.html I don’t recall you naming ADSP but it was certainly a group effort. If you want credit. Fine. But its editor was dead set against any Author Domain Policy model putting constraints on resigners. Reputation is all you need according to him. To his credit, he often admits it. >> >> But DMARC snuck in via M3 as an Informational status and since he can’t stop >> domains from using DMARC, he took over the editing of DMARCbis and now wants >> a MUST NOT p=reject without explaining how to best avoid its problems for >> existing systems. > > As one of the original organizers of the DMARC effort I object to your > characterization of DMARC as having "snuck in via M3”. It was “snucked” as an informational document because it was the only way to “fake” a standard on the public. Many RFCs came about this way. No way the original DMARC would pass as a Proposed Standard to get an RFC. It was fast tracked as an non-standard document. > As I have previously stated on this list, I disagree with the MUST NOT for > p=reject but I think you casting aspersions that John is trying to kill DMARC > is baseless and unfair. He has strong opinions about interoperability and > mail lists. We can’t kill DMARC because we could never kill the DKIM Policy concept. And this was the Editor’s problem - could not kill the high interest. Btw, you mentioned his name. No me. This is a problem I hope the IETF learns from where you can’t have an editor of a proposal when he does not believe in it, doesn’t champion it, doesn’t help fix it and has no interest in expanding on Tag Extensions when he knows there is big interest in this area. Instead, the DMARCBis editor works to keep out any author domain control of resigners outside the problematic exclusive p=reject policy. > >> As a proposed standard, there will be friction when ADSP was abandoned for >> reasons DMARCBis is not resolving other than saying don’t use restrictive >> domains. That’s what slowing this down. > > ADSP (nee SSP) had other issues and it wasn't so much killed as failed. There > were agreed upon compromises and it failed to gain traction. That sometimes > happens. True it has happened but not like the ADSP and DMARC saga. The problem there was always DKIM POLICY interest. It started with o= built in. Separated as SSP to help finished DKIM-BASE, reduced to ASP, published RFC as ADSP and he didn’t support it - period. That doesn’t happen unless you’re calling it an “Defensive RFC” to protect mailers from DMARC domain controls on mailers. Look I agreed with the idea that Local Policy prevails and as we later learned, when DMARC p=reject was being enabled by the industry, it forced the editor of ADSP and the now editor of DMARCBis to begin stripping down DMARC security. He needs to support DMARC security. Not crippled it. — HLS
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
