On Sat, Apr 22, 2023 at 2:04 PM Hector Santos <hsantos= [email protected]> wrote:
> > On Apr 22, 2023, at 12:58 PM, John Levine <[email protected]> wrote: > > It appears that Jesse Thompson <[email protected]> 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
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
