Barry, This is wrong. He knows his post was not off-list. His defamation of my character is out of line. But he does it to those disagrees with. He is smarting than all of us. So nothing knew.
Levine, editor of ADSP and the editor DMARCbis, needs to finally support DKIM Policy or give up editorship to a DKIM Policy Advocate engineer who does. You will see how fast it will be finished. This document will not change anything regarding p=reject but only promote a rewrite, tearing down DMARC security as the only solution. Even if he refuses to write about it he uses it to tear down the very essence of the document purpose in life. The long time interference with the high interest for a DKIM Policy solution needs to finally end. — HLS > On Apr 22, 2023, at 5:22 PM, John Levine <jo...@taugh.com> wrote: > > [[ rather off list ]] > > I think we all established a long time ago that the Internet that > Hector uses is very unlike the one the rest of us use, and it's not > worth arguing with him. > > That said, I really wish the chairs would shut down the trolls. They may > not think they're trolls, but they are having the classing trolling effect > of wasting time and driving people away. > > R's, > John > > > It appears that Dotzero <dotz...@gmail.com <mailto:dotz...@gmail.com>> said: >> -=-=-=-=-=- >> >> On Sat, Apr 22, 2023 at 2:04 PM Hector Santos <hsantos= >> 40isdg....@dmarc.ietf.org> wrote: >> >>> >>> On Apr 22, 2023, at 12:58 PM, John Levine <jo...@taugh.com> wrote: >>> >>> It appears that Jesse Thompson <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. >> >>> >>> 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". The DMARC effort >> coalesced when an earlier effort called MOOCOW organized by JD Falk failed. >> (I had declined to participate in MOOCOW because I believed early on that >> it was doomed to fail.) Yes, some of the DMARC meetings took place >> immediately preceding M3 meetings as a matter of convenience but many more >> took place online or were hosted by participating organizations at their >> offices. There were also other efforts as well. Anyone can go back to the >> archives of lists like DKIM-OPS circa 2007 to see me publicly stating a >> DMARC like approach in which I said that any emails being emitted by >> americangreetings.com that failed to pass either DKIM signed mail with a >>> From of americangreetings.com or SPF aligned with americangreetings.com >> should be discarded. This differed from the effort between PayPal and Yahoo >> which was based on private peering between two parties. >> >> 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. >> >> >>> >>> Yet, his answer to the DMARC problem, as a single implementation with IETF >>> list, is to strip the security of a domain using a Rewrite and does not >>> want to document it as a DMARCBis solution to the problem he refuses to >>> help fix, nor document the subscription/submission restrictions method, >>> something he could have done rather than introduce an unfortunate mail >>> engineering taboo to they industry - a new security loophole with caused by >>> this rewrite: >>> >>> Destroyed Mail Authorship Authentication Replays >>> >>> I almost believe he wants DMARCBis to fail as a Proposed Standard, >>> therefore refusing to also change it back to informational status as >>> suggested by Barry Leibre since it would give DMARCbis a better chance of >>> surviving IETF engineering scrutiny and passing last call. >>> >>> 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. >> >> I'll also digress and address Jim Fenton's comment about the Federal >> government not understanding the difference between informational and >> Standards track. DMARC wasn't submitted to IETF as informational until >> 2015. It was originally published by the dmarc.org team in 2011. Even prior >> to its original publication, the Federal government was looking for >> solutions to direct domain abuse. In 2010 there was an incident where >> someone sent an email purporting to be from the U.S. Senate (direct domain >> abuse) claiming that a Senator had been killed. There was also an incident >> where someone emailed what purported to be online Christmas cards (direct >> domain abuse) to people working at defense contractors resulting in >> compromises at various defense contractors. At the request of EOP >> (Executive Office of the President), Pat Peterson and I gave training on >> email authentication approaches which was turned into a virtual training >> environment accessible by government employees. We included the DMARC >> approach without actually naming DMARC because it hadn't been published yet >> and we were bound by the agreement among the DMARC participants. Other >> participants were aware that we were giving the training and that we would >> discuss the DMARC approach without naming it but simply mention a soon to >> be published standards effort. The request from EOP was passed to the CIO >> Council which delegated responsibility to DHS (Department of Homeland >> Security). This all took place well before DMARC was handed off to the >> IETF. There were also subsequent meetings I participated in with White >> House National Security staff. The wheels of government grind slowly. There >> were various government efforts to improve the mailing activities of >> various agencies and for those agencies to gain some modicum of control >> over mail flows. So no, implementation was not because the government >> doesn't understand IETF designations. It was a different scenario from >> !Yahoo and AOL, but the Federal Government had a problem with direct domain >> abuse and saw DMARC as a way of mitigating that problem. >> >> Michael Hammer >> >> -=-=-=-=-=- >> [Alternative: text/html] >> -=-=-=-=-=- > > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org <mailto:dmarc@ietf.org> > https://www.ietf.org/mailman/listinfo/dmarc
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
