Re: [dmarc-ietf] Definitely no Delegated authentication for Gmail
On-list meta-discussion is off topic. Please stop. Keep the discussion to technical topics that further the goal of arriving at solutions to open issues. Further discussion of this on the list will be subject to a 30-day ban from posting. Barry On Mon, Apr 24, 2023 at 6:02 PM Hector Santos wrote: > Barry, Please excuse any expressed anger. > > This is not the first time. The "Accidental Offline Post In Public On > Purpose" was intentional posted because he has done it before and it > will serves him no purpose to write his defamation of my character in > private. He got his defaming points out in publics. He has used the > tactic of creating chaos to get discussions killed and people shamed > as lacking credentials. He has done this many times and not just > with me. > > As an Internet Hosting implementator, I have been long participated in > IETF related work and I have been acknowledged by many of the IETF > work. I have supported most of the proposals if not all the main ones > for SMTP. > > Levine and I got off the wrong foot when he started the IRTF "LMAP > Group" that just started SPF.I presented my 2003-2005 two years > work with CBV call back verification and he kicked me out of the > group. He called my customers stupid, rejects all my email and its > been sour ever since, only this time, I am seriously contemplating a > defamation lawsuit. > > Since he "hijacked" and I will say it strongly, SSP, with a crippled > ADSP with the main purpose to remove all 3rd party talk, we, the DKIM > and DMARC WG has been in this non-resolution bind for the last 17 > years leaving loopholes in the DKIM policy model called DMARC. We > need to admit this truth because this interference to prevent TPA > concepts has stopped completing this project. He should of never been > giving editorship or gatekeeper of ADSP and now DMARCbis because > nothing will get accomplished towards DKIM Policy issues and DMARC > risk calling the same hole ADSP did. > > Unfortunately, he is repeating it again with DMARCbis. He sees > interest in author/signer protocols and he immediately jumps in to > kill it, like he has done in the past, by defaming people, telling > people not to respond, telling people we are trolls and that we scare > people away. > > What should I do now? He did this for nearly 20 years and I don't > like it. > > I am not going to go away again like I did in 2012 when all the stress > was not good for my health and I was forced to take a long 6-8 years > health sabbatical. I stayed away from here as much as I could, > watching a promising system get pushed aside for business conflicts -- > Reputation services. Remember Levine's Domain Assurance Council using > VBR? > > https://en.wikipedia.org/wiki/Domain_Assurance_Council > > I am not making this up. This was the start of all the resistance to > DKIM Policy. He took over ADSP but didn't support it. > > I don't explain why. Maybe he felt DKIM POLICY would had controlled > the market of resigners and this is why he had Section 5.3, Item 10 > added to the functional specs - don't try to INPURGN on 3rd party > services -- local policy. Hard to argue. It was hitting a promising > framework in the knees with a hammer!! > > Barry, lets just get this finished, a document that endorses DKIM > POLICY add-on methods. With the support of the IETF without the long > time interference will go a long way to completing this. The industry > has been damaged with Levine's rewrite hack/taboo. Who does that and > is also the editor of DMARCbis? Is it for it or against it? It seems > illogical. Conflict of Interest. Please lets try to fix it. > > Can there ever be proposed text to suggest a smooth transition to > DMARCbis endorsing 3rd party authorization exploration and solutions? > > Maybe when it is endorsed we can get the enterprises to at least do > verification, even if they can use it themselves for outbound mail. > > > -- > HLS > > On 4/24/2023 4:49 PM, Barry Leiba wrote: > > Ok, everyone, let’s take a rest here. > > > > First: John’s message was not nice. We can all agree on that. So… > > > > (1) John, please don’t send messages like that, even off list. You > > can clearly see why that’s good advice. > > > > (2) Everyone other than John, please just accept John’s word — I do > > — that sending it to the list was accidental, and that he did not > > mean to publicly disparage or embarrass anyone. What happened is > > regrettable. Let’s be bigger than the error and get past it. Thanks. > > > > Second: this whole thread is well beyond the scope of what the > > working group is chartered to do. I’ve let these sorts of > > discussions go because I hoped they might lead us in a useful > > direction. It’s become very clear that they will not, and that they > > are just distractions that prevent us from resolving the issues at > > hand and finishing the chartered work. > > > > So… > > > > (1) Please stop this and related threads, and please
Re: [dmarc-ietf] Definitely no Delegated authentication for Gmail
Barry, Please excuse any expressed anger. This is not the first time. The "Accidental Offline Post In Public On Purpose" was intentional posted because he has done it before and it will serves him no purpose to write his defamation of my character in private. He got his defaming points out in publics. He has used the tactic of creating chaos to get discussions killed and people shamed as lacking credentials. He has done this many times and not just with me. As an Internet Hosting implementator, I have been long participated in IETF related work and I have been acknowledged by many of the IETF work. I have supported most of the proposals if not all the main ones for SMTP. Levine and I got off the wrong foot when he started the IRTF "LMAP Group" that just started SPF.I presented my 2003-2005 two years work with CBV call back verification and he kicked me out of the group. He called my customers stupid, rejects all my email and its been sour ever since, only this time, I am seriously contemplating a defamation lawsuit. Since he "hijacked" and I will say it strongly, SSP, with a crippled ADSP with the main purpose to remove all 3rd party talk, we, the DKIM and DMARC WG has been in this non-resolution bind for the last 17 years leaving loopholes in the DKIM policy model called DMARC. We need to admit this truth because this interference to prevent TPA concepts has stopped completing this project. He should of never been giving editorship or gatekeeper of ADSP and now DMARCbis because nothing will get accomplished towards DKIM Policy issues and DMARC risk calling the same hole ADSP did. Unfortunately, he is repeating it again with DMARCbis. He sees interest in author/signer protocols and he immediately jumps in to kill it, like he has done in the past, by defaming people, telling people not to respond, telling people we are trolls and that we scare people away. What should I do now? He did this for nearly 20 years and I don't like it. I am not going to go away again like I did in 2012 when all the stress was not good for my health and I was forced to take a long 6-8 years health sabbatical. I stayed away from here as much as I could, watching a promising system get pushed aside for business conflicts -- Reputation services. Remember Levine's Domain Assurance Council using VBR? https://en.wikipedia.org/wiki/Domain_Assurance_Council I am not making this up. This was the start of all the resistance to DKIM Policy. He took over ADSP but didn't support it. I don't explain why. Maybe he felt DKIM POLICY would had controlled the market of resigners and this is why he had Section 5.3, Item 10 added to the functional specs - don't try to INPURGN on 3rd party services -- local policy. Hard to argue. It was hitting a promising framework in the knees with a hammer!! Barry, lets just get this finished, a document that endorses DKIM POLICY add-on methods. With the support of the IETF without the long time interference will go a long way to completing this. The industry has been damaged with Levine's rewrite hack/taboo. Who does that and is also the editor of DMARCbis? Is it for it or against it? It seems illogical. Conflict of Interest. Please lets try to fix it. Can there ever be proposed text to suggest a smooth transition to DMARCbis endorsing 3rd party authorization exploration and solutions? Maybe when it is endorsed we can get the enterprises to at least do verification, even if they can use it themselves for outbound mail. -- HLS On 4/24/2023 4:49 PM, Barry Leiba wrote: Ok, everyone, let’s take a rest here. First: John’s message was not nice. We can all agree on that. So… (1) John, please don’t send messages like that, even off list. You can clearly see why that’s good advice. (2) Everyone other than John, please just accept John’s word — I do — that sending it to the list was accidental, and that he did not mean to publicly disparage or embarrass anyone. What happened is regrettable. Let’s be bigger than the error and get past it. Thanks. Second: this whole thread is well beyond the scope of what the working group is chartered to do. I’ve let these sorts of discussions go because I hoped they might lead us in a useful direction. It’s become very clear that they will not, and that they are just distractions that prevent us from resolving the issues at hand and finishing the chartered work. So… (1) Please stop this and related threads, and please avoid discussions that are not in direct resolution of open issues. (2) Be aware that the chairs will be getting aggressive about shutting down out-of-scope discussions quickly. I will put the mailing list on moderation if necessary, which would mean that every post would need approval before it’s posted to the list. I’d rather not spend my time that way; please don’t make it necessary. Barry, as chair
Re: [dmarc-ietf] Definitely no Delegated authentication for Gmail
Ok, everyone, let’s take a rest here. First: John’s message was not nice. We can all agree on that. So… (1) John, please don’t send messages like that, even off list. You can clearly see why that’s good advice. (2) Everyone other than John, please just accept John’s word — I do — that sending it to the list was accidental, and that he did not mean to publicly disparage or embarrass anyone. What happened is regrettable. Let’s be bigger than the error and get past it. Thanks. Second: this whole thread is well beyond the scope of what the working group is chartered to do. I’ve let these sorts of discussions go because I hoped they might lead us in a useful direction. It’s become very clear that they will not, and that they are just distractions that prevent us from resolving the issues at hand and finishing the chartered work. So… (1) Please stop this and related threads, and please avoid discussions that are not in direct resolution of open issues. (2) Be aware that the chairs will be getting aggressive about shutting down out-of-scope discussions quickly. I will put the mailing list on moderation if necessary, which would mean that every post would need approval before it’s posted to the list. I’d rather not spend my time that way; please don’t make it necessary. Barry, as chair ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Definitely no Delegated authentication for Gmail
Well John, we have some things to talk about, and it will have to be in public. You should remember that you blocked me from direct communication when I tried to start a side conversation about improving ARC. I conclude that I am one of the trolls that gets in your way, since I have been driving the current topic. You seem to be sorry for calling me names in public, rather than repenting for the attitude behind it. Consequently, the apology must have been intended for the chairs, and I trust they will accept it. For my part, I have learned to forgive quickly because I have been forgiven of much. For my part, I am sorry that you don't like me.I try to follow the Biblical maxim that says, "to the extent it lies within you, live at peace with all men." Usually, I am successful. I have searched my own attitude toward this group in hopes that I am not disliked with reason. It certainly seems that our relationship soured because I was adamantly opposed to Dave Crocker's proposal, which repudiated From authentication as an illegitimate concept, and sought to replace DMARC with impersonation for everyone. I joined this group expecting to say little and learn much, but suddenly I was the only defender of the status quo, so silence was not an option. You said in the course of that discussion, "Would you be surprised if I told you that the From address is not important to me?" I believe you also said that DMARC has done more harm than good. Oddly, the chairs were happy to let the Crocker discussion fester for a long time. Dave frequently repeated his original assertions, without modification, even after they had been thoroughly debunked in the discussion. The chairs only objected when I accused Dave of not listening to me, which was evident. They assured me that participants had no obligation to listen to each other. Eventually, Scott jumped in and settled the matter with, "this is not DMARC." I remain a lot confused by your change in roles. After being DMARC's fiercest enemy, you became entrenched as the one who controlled what DMARCbis has become, and the current draft is unimportantly different from the original. I was also surprised when Scott became your strong ally. To be clear, this has become your document. Your most powerful weapon is silence, but when talk is needed you have allies who will solidify your power and your control on this document. Nothing made this more obvious than when you said your personal preference would override any pretense of consensus, and the chairs let that announcement stand unchallenged. Unfortunately, limiting the document to one viewpoint has introduced weaknesses. I am confident that you can move DMARCbis to publication, but I will most likely ask for my name to be removed, since I have been prevented from having a meaningful role in avoiding those weaknesses. The process of creating this document has been slow, so I sympathize with your frustration. My wife calls this group "my mistress", because it takes so much personal time and because it has dragged on for so long. (It was illuminating to hear that the original document was completed in 18 months.) But your control works against progress, not in favor of it. Topics which are ignored tend to keep coming back. We have a strange and difficult assignment: a very small group of people are supposed to figure out what is in the general interest of the large subset of 8 billion people who will either use email or be affected by other's use of email. The intended path to that outcome is collaboration, with each of us contributing our individual understanding of what is needed to achieve that goal. Too much of this archive is filled with combativeness, rather than collaboration, for which I mostly blame the chairs. Which brings us back to my part of the collaboration. I came to this group from my role as an evaluator of an incoming mail stream, frustrated with the vendors who are supposed to protect us, and eager to find a way to improve email defenses against the combined effects of malicious actors and bungling vendors. I had little experience with mailing lists, and my early participation was not sympathetic to them. But the Crocker discussion did change me. I have been looking, ever since, for ways to bring mailing lists into the authentication world, even while expressing my frustration that the problem is one of their own making. After multiple other options have been considered and failed, I have landed on ATPS as a solution which is pretty well suited to the problem that the Crocker proposal was trying to fix. It is a very serious proposal, and not an attempt to waste your time. I hoped you and other mailing list advocates would be excited, and hoped that you specifically would turn your considerable brain power toward turning the concept into reality. Instead, you are annoyed and the other power players have been oddly silent. I am ready to collaborate on
Re: [dmarc-ietf] Definitely no Delegated authentication for Gmail
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 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 mailto:dotz...@gmail.com>> said: >> -=-=-=-=-=- >> >> On Sat, Apr 22, 2023 at 2:04 PM Hector Santos > 40isdg@dmarc.ietf.org> wrote: >> >>> >>> On Apr 22, 2023, at 12:58 PM, John Levine wrote: >>> >>> It appears that Jesse Thompson 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
Re: [dmarc-ietf] Definitely no Delegated authentication for Gmail
[[ 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 said: >-=-=-=-=-=- > >On Sat, Apr 22, 2023 at 2:04 PM Hector Santos 40isdg@dmarc.ietf.org> wrote: > >> >> On Apr 22, 2023, at 12:58 PM, John Levine wrote: >> >> It appears that Jesse Thompson 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
Re: [dmarc-ietf] Definitely no Delegated authentication for Gmail
On Sat, Apr 22, 2023 at 2:04 PM Hector Santos wrote: > > On Apr 22, 2023, at 12:58 PM, John Levine wrote: > > It appears that Jesse Thompson 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
Re: [dmarc-ietf] Definitely no Delegated authentication for Gmail
> On Apr 22, 2023, at 12:58 PM, John Levine wrote: > > It appears that Jesse Thompson 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. 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. 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. — HLS___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Definitely no Delegated authentication for Gmail
I am aware nobody is using ATSP. I have not seen an assessment of why nobody. The current implementation seems competitive with DKIM, which is my explanation for it's failure. Extending ATSP for user-to-domain, would address new functionality which addresses the large unsolved problem in our charter. Evading the problem by telling people not to use DMARC is not a solution. Admitting failure is an option, and I have been close to that on several occasions. But as of today, I think failure is unnecessary. I think the data hiding problem can be solved. I also like Ale's recipient authentication approach. The two approaches can be used in parallel. DF On Sat, Apr 22, 2023, 12:58 PM John Levine wrote: > It appears that Jesse Thompson 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. > > Nobody uses ATSP, nobody is going to use ATSP, this is just yet more > distraction and wheel spinning that is keeping us from finishing. > > R's, > John > > ___ > 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] Definitely no Delegated authentication for Gmail
It appears that Jesse Thompson 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. Nobody uses ATSP, nobody is going to use ATSP, this is just yet more distraction and wheel spinning that is keeping us from finishing. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
