Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field
On 9/26/2020 7:23 PM, Seth Blank wrote: The goal of DMARCbis is to take the independent stream informational RFC 7489 and drive it to an IETF stream standards track document that represents IETF consensus. So this work is explicitly around DMARC as a protocol that describes how a domain owner transmits its policy for mail that does not authenticate to a mail receiver. Further, our charter takes the usefulness of DMARC in its current form as table stakes, and (to paraphrase) primarily focuses our discussion around addressing limitations or operational concerns of the protocol. One of the primary limitations of DMARC is when mail transits through a forwarder that breaks authentication. For DMARC to go standards track, this issue must be addressed. Currently ARC is the approved experiment from Phase 2 of our Charter. Seth, as Chair Thanks for the summary. Are any of authorized third party proposals on the table? -- Hector Santos, https://secure.santronics.com https://twitter.com/hectorsantos ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field
On Sat, Sep 26, 2020 at 3:50 PM Scott Kitterman wrote: > Is the context in terms of the protocol specified by RFC 7489? > Yes. > That may sound like a silly question, but I think fundamentally if "DMARC" > is > just an input to a filter or if "DMARC" is a protocol to reject/quarantine > email that meets certain policy criteria makes a big difference in how > some of > these questions are addressed. > The goal of DMARCbis is to take the independent stream informational RFC 7489 and drive it to an IETF stream standards track document that represents IETF consensus. So this work is explicitly around DMARC as a protocol that describes how a domain owner transmits its policy for mail that does not authenticate to a mail receiver. Further, our charter takes the usefulness of DMARC in its current form as table stakes, and (to paraphrase) primarily focuses our discussion around addressing limitations or operational concerns of the protocol. One of the primary limitations of DMARC is when mail transits through a forwarder that breaks authentication. For DMARC to go standards track, this issue must be addressed. Currently ARC is the approved experiment from Phase 2 of our Charter. Seth, as Chair ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field
On Saturday, September 26, 2020 3:56:44 PM EDT Seth Blank wrote: > Thank you, everyone, for backing off the personal attacks and apologizing. > > Now let's get back to the technical merits of the open tickets, please-- > we'd like to close the current 3 out and open the next batch early next > week. Is the context in terms of the protocol specified by RFC 7489? That may sound like a silly question, but I think fundamentally if "DMARC" is just an input to a filter or if "DMARC" is a protocol to reject/quarantine email that meets certain policy criteria makes a big difference in how some of these questions are addressed. If I'm going to dive into details, I want to first make sure I understand the context. Scott K ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field
... Well, ok, here's one that shows lack of efficacy, and it's a big one: EV-certs /Google to bury indicator for Extended Validation certs in Chrome because users barely took notice/ https://www.theregister.com/2019/08/12/google_chrome_extended_validation_certificates/ "The reason is simple. "Through our own research as well as a survey of prior academic work, the Chrome Security UX team has determined that the EV UI does not protect users as intended... users do not appear to make secure choice..." To be fair, this is looking at positive security indicators, not negative ones. But there are plenty of other studies looking at the more general case. Here's one that seems relevant to DMARC: Do Security Toolbars Actually Prevent Phishing Attacks? https://dl.acm.org/doi/pdf/10.1145/1124772.1124863 Abstract: Security toolbars in a web browser show security-related information about a website to help users detect phishing attacks. Because the toolbars are designed for humans to use, they should be evaluated for usability - that is, whether these toolbars really prevent users from being tricked into providing personal information. We conducted two user studies of three security toolbars and other browser security indicators and found them all ineffective at preventing phishing attacks. Even though subjects were asked to pay attention to the toolbar, many failed to look at it; others disregarded or explained away the toolbars' warnings if the content of web pages looked legitimate. We found that many subjects do not understand phishing attacks or realize how sophisticated such attacks can be. Ned ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field
On Saturday, September 26, 2020 3:59:50 PM EDT Dave Crocker wrote: > On 9/26/2020 8:41 AM, Scott Kitterman wrote: > > On Friday, September 25, 2020 11:03:51 PM EDT Dave Crocker wrote: > >> Perhaps you have not noticed but the demonstrated field use of DMARC, to > >> date, tends to be contrary to the design, to the extent anyone thinks > >> that the design carries a mandate that receivers follow the directives > >> of the domain owners. > >> > >> So the text in the draft merely reflects real-world operational style. > > > > I think it's not nearly as clear as you seem to think. If the standard is > > users will not 100% do the right thing, then I agree that won't happen, > > but I don't think it's a reasonable standard. I think the standard ought > > to be that there is an overall tendency towards reduced risk. > > And there is no (or perhaps only minuscule) evidence that such a > tendency is demonstrated. > > Even the 'study' you cited uses the word 'slight'. > > The larger question is: where is the body of research and/or experience > that demonstrates the positive effect you are relying on? As far as I > know "trust indicators" have somewhere between a poor and a terrible > history. So to the extent you believe they are helpful, please produce > the body of work demonstrating it. > > My real point is that we /know/ there is a critical and demonstrably > useful -- actually, essential -- function performed by anti-abuse > filtering engines at receivers, independent of the end-user. Good ones > reduce incoming abuse down from roughly 95% of the stream to a tiny > percent. > > DMARC processing is included in some such engines' repertoire. > > The proposal adds to that, but based on the Sender: field, rather than > the From: field. > > > My claim is that this proposal is substantially at odds with the protocol > > as documented (#1). > > I disagree. > > Again, please clarify exactly how it is at odds and please explain in > detail what real-world processing of DMARC it impedes. > > > I think we agree that this proposal is at odds with DMARC as documented. > > We do not agree. > > Again, rather than making a broad claim, please provide actual detail to > substantiate your claim. Since I've been directed to stop this discussion by one of the chairs, I guess we'll save it for last call. Scott K ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field
On 9/26/2020 8:41 AM, Scott Kitterman wrote: On Friday, September 25, 2020 11:03:51 PM EDT Dave Crocker wrote: Perhaps you have not noticed but the demonstrated field use of DMARC, to date, tends to be contrary to the design, to the extent anyone thinks that the design carries a mandate that receivers follow the directives of the domain owners. So the text in the draft merely reflects real-world operational style. I think it's not nearly as clear as you seem to think. If the standard is users will not 100% do the right thing, then I agree that won't happen, but I don't think it's a reasonable standard. I think the standard ought to be that there is an overall tendency towards reduced risk. And there is no (or perhaps only minuscule) evidence that such a tendency is demonstrated. Even the 'study' you cited uses the word 'slight'. The larger question is: where is the body of research and/or experience that demonstrates the positive effect you are relying on? As far as I know "trust indicators" have somewhere between a poor and a terrible history. So to the extent you believe they are helpful, please produce the body of work demonstrating it. My real point is that we /know/ there is a critical and demonstrably useful -- actually, essential -- function performed by anti-abuse filtering engines at receivers, independent of the end-user. Good ones reduce incoming abuse down from roughly 95% of the stream to a tiny percent. DMARC processing is included in some such engines' repertoire. The proposal adds to that, but based on the Sender: field, rather than the From: field. My claim is that this proposal is substantially at odds with the protocol as documented (#1). I disagree. Again, please clarify exactly how it is at odds and please explain in detail what real-world processing of DMARC it impedes. I think we agree that this proposal is at odds with DMARC as documented. We do not agree. Again, rather than making a broad claim, please provide actual detail to substantiate your claim. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field
Thank you, everyone, for backing off the personal attacks and apologizing. Now let's get back to the technical merits of the open tickets, please-- we'd like to close the current 3 out and open the next batch early next week. On Sat, Sep 26, 2020 at 12:08 PM Douglas E. Foster wrote: > My apology, Dave, for letting my frustration get the best of me. > > > > Doug Foster > > > > > -- > *From*: Tim Wicinski > *Sent*: 9/26/20 12:33 PM > *To*: fost...@bayviewphysicians.com > *Cc*: "dmarc@ietf.org" > *Subject*: Re: [dmarc-ietf] Call for Adoption: DMARC Use of the > RFC5322.Sender Header Field > > > And here we were getting along so well! > > Mr Foster, it's perfectly fine to disagree with Mr Crocker technical > points, and you are > welcome to have your own opinion on whether he chooses to hear or not. > But those opinions should > be kept to yourself. > > I see a lot of these heated discussions as a sign that people really care > about this issue. That's > a good thing. > > For the record, I'm a DNS person. I see most problems as being solved > with more DNS, or less DNS. > I will say that I have had "passionate discussions" with Mr Crocker on > several issues and I found that > it was not that he did not listen, but figuring out how to better explain > my point of view. > Surprisingly to many, he does listen. > > Whether this work is in scope for DMARC or not, I would plead guilty for > not considering this carefully. > In the DNSOP working group I co-chair, *everything* DNS is in scope, until > it is not in scope. > These types of discussions I was leaning on Seth, Alexey and of course > Murray the AD. > > thanks for listening. > tim > > > On Sat, Sep 26, 2020 at 8:55 AM Douglas E. Foster 40bayviewphysicians@dmarc.ietf.org> wrote: > >> The problems with your proposal have been well documented, but you >> apparently choose not to hear. The single paragraph that Scott quoted has >> multiple problems within it. >> >> The group has considered other and better technical proposals >> (conditional signatures, ATSP, RHSWL), but they have all been dropped >> because the group did not believe that Domain Owners would have any desire >> to implement them, and because Mailing List Operators would have no way of >> knowing which mailing lists had implemented the new feature. >> >> If you have solutions to these problems, please put them forward. >> Otherwise, why are we dragging this back up? >> >> >> -- >> *From*: Dave Crocker >> *Sent*: 9/25/20 11:04 PM >> *To*: Scott Kitterman >> *Cc*: IETF DMARC WG >> *Subject*: Re: [dmarc-ietf] Call for Adoption: DMARC Use of the >> RFC5322.Sender Header Field >> >> On 9/25/2020 4:21 PM, Scott Kitterman wrote: >> >> On Friday, September 25, 2020 7:05:22 PM EDT Dave Crocker wrote: >> >> I think the obligation to justify is on the advocate for change. >> >> That means you are demanding I prove negative. Which, of course, is an >> impossible assignment. >> >> Rather, the obligation is on the person claiming the affirmative, which >> in this case means the claim that this proposal somehow 'breaks' or >> otherwise hurts DMARC. >> >> >> Because the current email protection behavior involves the >>RFC5322.From field, and pertain to the human author, it is common to >>think that the issue, in protecting the field's content, is behavior >>of the human recipient. However there is no indication that the >>enforced values in the RFC5322.From field alter end-user behavior. >>In fact there is a long train of indication that it does not. >> Rather, the meaningful protections actually operate at the level of >>the receiving system's mail filtering engine, which decides on the >>dispostion of received mail. >> >> Please provide references for your long train of indications, speaking of >> making overly broad assumptions. If that's accurate, I'd like to understand >> the data that tells us that. >> >> I'm not going to do that, because there's a long history of that work >> being ignored, in spite of it being reviewed repeatedly in thse and related >> fora over the years. It's gotten tiresome to have people claiming an >> effect that they lacks evidence for, and the data to the contrary that they >> are somehow unaware of. >> >> Again, the real requirement is focus on the affirmative. >> >> In this case, an affirmative claim that end-users are relevant to the >> efficacy of DMARC. I don't recall seeing any research results validating >> such a view, but perhaps I missed it. >> >> Well, ok, here's one that shows lack of efficacy, and it's a big one: >> EV-certs >> >> *Google to bury indicator for Extended Validation certs in Chrome because >> users barely took notice* >> >> >> https://www.theregister.com/2019/08/12/google_chrome_extended_validation_certificates/ >> >> "The reason is simple. "Through our own research as well as a survey of >> prior academic work, the Chrome Security UX team h
Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field
My apology, Dave, for letting my frustration get the best of me. Doug Foster From: Tim Wicinski Sent: 9/26/20 12:33 PM To: fost...@bayviewphysicians.com Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field And here we were getting along so well! Mr Foster, it's perfectly fine to disagree with Mr Crocker technical points, and you are welcome to have your own opinion on whether he chooses to hear or not. But those opinions should be kept to yourself. I see a lot of these heated discussions as a sign that people really care about this issue. That's a good thing. For the record, I'm a DNS person. I see most problems as being solved with more DNS, or less DNS. I will say that I have had "passionate discussions" with Mr Crocker on several issues and I found that it was not that he did not listen, but figuring out how to better explain my point of view. Surprisingly to many, he does listen. Whether this work is in scope for DMARC or not, I would plead guilty for not considering this carefully. In the DNSOP working group I co-chair, *everything* DNS is in scope, until it is not in scope. These types of discussions I was leaning on Seth, Alexey and of course Murray the AD. thanks for listening. tim On Sat, Sep 26, 2020 at 8:55 AM Douglas E. Foster wrote: The problems with your proposal have been well documented, but you apparently choose not to hear. The single paragraph that Scott quoted has multiple problems within it. The group has considered other and better technical proposals (conditional signatures, ATSP, RHSWL), but they have all been dropped because the group did not believe that Domain Owners would have any desire to implement them, and because Mailing List Operators would have no way of knowing which mailing lists had implemented the new feature. If you have solutions to these problems, please put them forward. Otherwise, why are we dragging this back up? From: Dave Crocker Sent: 9/25/20 11:04 PM To: Scott Kitterman Cc: IETF DMARC WG Subject: Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field On 9/25/2020 4:21 PM, Scott Kitterman wrote:On Friday, September 25, 2020 7:05:22 PM EDT Dave Crocker wrote:I think the obligation to justify is on the advocate for change. That means you are demanding I prove negative. Which, of course, is an impossible assignment. Rather, the obligation is on the person claiming the affirmative, which in this case means the claim that this proposal somehow 'breaks' or otherwise hurts DMARC. Because the current email protection behavior involves the RFC5322.From field, and pertain to the human author, it is common to think that the issue, in protecting the field's content, is behavior of the human recipient. However there is no indication that the enforced values in the RFC5322.From field alter end-user behavior. In fact there is a long train of indication that it does not. Rather, the meaningful protections actually operate at the level of the receiving system's mail filtering engine, which decides on the dispostion of received mail. Please provide references for your long train of indications, speaking of making overly broad assumptions. If that's accurate, I'd like to understand the data that tells us that. I'm not going to do that, because there's a long history of that work being ignored, in spite of it being reviewed repeatedly in thse and related fora over the years. It's gotten tiresome to have people claiming an effect that they lacks evidence for, and the data to the contrary that they are somehow unaware of. Again, the real requirement is focus on the affirmative. In this case, an affirmative claim that end-users are relevant to the efficacy of DMARC. I don't recall seeing any research results validating such a view, but perhaps I missed it. Well, ok, here's one that shows lack of efficacy, and it's a big one: EV-certs Google to bury indicator for Extended Validation certs in Chrome because users barely took notice https://www.theregister.com/2019/08/12/google_chrome_extended_validation_certificates/ "The reason is simple. "Through our own research as well as a survey of prior academic work, the Chrome Security UX team has determined that the EV UI does not protect users as intended... users do not appear to make secure choice..." If this is just an input into an algorithm, then your assertion that you are only providing another input is supportable, but that's contrary to the DMARC design. Perhaps you have not noticed but the demonstrated field use of DMARC, to date, tends to be contrary to the design, to the extent anyone thinks that the design carries a mandate that receivers follow the directives of the domain owners. So the text in the draft merely reflects real-world operational style. d/ -- Dave Crocker Brandenburg
Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field
On Sat, 26 Sep 2020, John Levine wrote: In article you write: Chairs? [ something ] My apologies, that wasn't supposed to go to the list. Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field
On 9/26/2020 10:19 AM, John Levine wrote: I thought he was already in everone's kill file. John, That's also an ad homen. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field
In article you write: >On 9/26/2020 5:55 AM, Douglas E. Foster wrote: >> but you apparently choose not to hear. > > >that's an ad hominem. > >Chairs? I thought he was already in everone's kill file. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field
And here we were getting along so well! Mr Foster, it's perfectly fine to disagree with Mr Crocker technical points, and you are welcome to have your own opinion on whether he chooses to hear or not. But those opinions should be kept to yourself. I see a lot of these heated discussions as a sign that people really care about this issue. That's a good thing. For the record, I'm a DNS person. I see most problems as being solved with more DNS, or less DNS. I will say that I have had "passionate discussions" with Mr Crocker on several issues and I found that it was not that he did not listen, but figuring out how to better explain my point of view. Surprisingly to many, he does listen. Whether this work is in scope for DMARC or not, I would plead guilty for not considering this carefully. In the DNSOP working group I co-chair, *everything* DNS is in scope, until it is not in scope. These types of discussions I was leaning on Seth, Alexey and of course Murray the AD. thanks for listening. tim On Sat, Sep 26, 2020 at 8:55 AM Douglas E. Foster wrote: > The problems with your proposal have been well documented, but you > apparently choose not to hear. The single paragraph that Scott quoted has > multiple problems within it. > > The group has considered other and better technical proposals (conditional > signatures, ATSP, RHSWL), but they have all been dropped because the group > did not believe that Domain Owners would have any desire to implement them, > and because Mailing List Operators would have no way of knowing which > mailing lists had implemented the new feature. > > If you have solutions to these problems, please put them forward. > Otherwise, why are we dragging this back up? > > -- > *From*: Dave Crocker > *Sent*: 9/25/20 11:04 PM > *To*: Scott Kitterman > *Cc*: IETF DMARC WG > *Subject*: Re: [dmarc-ietf] Call for Adoption: DMARC Use of the > RFC5322.Sender Header Field > > On 9/25/2020 4:21 PM, Scott Kitterman wrote: > > On Friday, September 25, 2020 7:05:22 PM EDT Dave Crocker wrote: > > I think the obligation to justify is on the advocate for change. > > That means you are demanding I prove negative. Which, of course, is an > impossible assignment. > > Rather, the obligation is on the person claiming the affirmative, which in > this case means the claim that this proposal somehow 'breaks' or otherwise > hurts DMARC. > > > Because the current email protection behavior involves the >RFC5322.From field, and pertain to the human author, it is common to >think that the issue, in protecting the field's content, is behavior >of the human recipient. However there is no indication that the >enforced values in the RFC5322.From field alter end-user behavior. >In fact there is a long train of indication that it does not. > Rather, the meaningful protections actually operate at the level of >the receiving system's mail filtering engine, which decides on the >dispostion of received mail. > > Please provide references for your long train of indications, speaking of > making overly broad assumptions. If that's accurate, I'd like to understand > the data that tells us that. > > I'm not going to do that, because there's a long history of that work > being ignored, in spite of it being reviewed repeatedly in thse and related > fora over the years. It's gotten tiresome to have people claiming an > effect that they lacks evidence for, and the data to the contrary that they > are somehow unaware of. > > Again, the real requirement is focus on the affirmative. > > In this case, an affirmative claim that end-users are relevant to the > efficacy of DMARC. I don't recall seeing any research results validating > such a view, but perhaps I missed it. > > Well, ok, here's one that shows lack of efficacy, and it's a big one: > EV-certs > > *Google to bury indicator for Extended Validation certs in Chrome because > users barely took notice* > > > https://www.theregister.com/2019/08/12/google_chrome_extended_validation_certificates/ > > "The reason is simple. "Through our own research as well as a survey of > prior academic work, the Chrome Security UX team has determined that the EV > UI does not protect users as intended... users do not appear to make secure > choice..." > > > If this is just an input into an algorithm, then your assertion that you are > only providing another input is supportable, but that's contrary to the DMARC > design. > > Perhaps you have not noticed but the demonstrated field use of DMARC, to > date, tends to be contrary to the design, to the extent anyone thinks that > the design carries a mandate that receivers follow the directives of the > domain owners. > > So the text in the draft merely reflects real-world operational style. > > > d/ > > -- > Dave Crocker > Brandenburg InternetWorkingbbiw.net > > ___ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/list
Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field
On Friday, September 25, 2020 11:03:51 PM EDT Dave Crocker wrote: > On 9/25/2020 4:21 PM, Scott Kitterman wrote: > > On Friday, September 25, 2020 7:05:22 PM EDT Dave Crocker wrote: > > I think the obligation to justify is on the advocate for change. > > That means you are demanding I prove negative. Which, of course, is an > impossible assignment. > > Rather, the obligation is on the person claiming the affirmative, which > in this case means the claim that this proposal somehow 'breaks' or > otherwise hurts DMARC. I suspect we are going to continue to disagree on this, but I think it's a very odd claim that your assertions should be assumed to be correct. > > Because the current email protection behavior involves the > > > > RFC5322.From field, and pertain to the human author, it is common to > > think that the issue, in protecting the field's content, is behavior > > of the human recipient. However there is no indication that the > > enforced values in the RFC5322.From field alter end-user behavior. > > In fact there is a long train of indication that it does not. > > > >Rather, the meaningful protections actually operate at the level of > > > > the receiving system's mail filtering engine, which decides on the > > dispostion of received mail. > > > > Please provide references for your long train of indications, speaking of > > making overly broad assumptions. If that's accurate, I'd like to > > understand the data that tells us that. > > I'm not going to do that, because there's a long history of that work > being ignored, in spite of it being reviewed repeatedly in thse and > related fora over the years. It's gotten tiresome to have people > claiming an effect that they lacks evidence for, and the data to the > contrary that they are somehow unaware of. > > Again, the real requirement is focus on the affirmative. > > In this case, an affirmative claim that end-users are relevant to the > efficacy of DMARC. I don't recall seeing any research results > validating such a view, but perhaps I missed it. > > Well, ok, here's one that shows lack of efficacy, and it's a big one: > EV-certs > > /Google to bury indicator for Extended Validation certs in Chrome > because users barely took notice/ > > https://www.theregister.com/2019/08/12/google_chrome_extended_validation_cer > tificates/ > > "The reason is simple. "Through our own research as well as a survey of > prior academic work, the Chrome Security UX team has determined that the > EV UI does not protect users as intended... users do not appear to make > secure choice..." > > > If this is just an input into an algorithm, then your assertion that you > > are only providing another input is supportable, but that's contrary to > > the DMARC design. > > Perhaps you have not noticed but the demonstrated field use of DMARC, to > date, tends to be contrary to the design, to the extent anyone thinks > that the design carries a mandate that receivers follow the directives > of the domain owners. > > So the text in the draft merely reflects real-world operational style. I think it's not nearly as clear as you seem to think. If the standard is users will not 100% do the right thing, then I agree that won't happen, but I don't think it's a reasonable standard. I think the standard ought to be that there is an overall tendency towards reduced risk. Somewhat related to your example, these things aren't always entirely straightforward: https://emilymstark.com/2020/07/14/debunking-the-users-always-click-yes-myth.html However, I suspect we are not going to agree on that either. Relative to the does this proposal change DMARC question, based on your feedback, I think we actually mostly agree. Any protocol exists in at least two variants: 1. As documented in specifications such as RFCs 2. As used in the real world. Ideally those would be identical, but they never are. My claim is that this proposal is substantially at odds with the protocol as documented (#1). If I understand your position correctly, you are claiming that your proposal is aligned to the protocol as actually used (#2). Is that correct? Assuming that it does for a moment to save a round trip on emails: I think we agree that this proposal is at odds with DMARC as documented. Is it correct that you believe the WG can/should ignore that and focus on DMARC as it is used operationally? Scott K ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field
On 9/26/2020 5:55 AM, Douglas E. Foster wrote: but you apparently choose not to hear. that's an ad hominem. Chairs? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field
On 9/26/2020 3:31 AM, Alessandro Vesely wrote: A pointer to a better aimed report circulated on this list: An unrefereed presentation (not paper) about a single experiment is better than a summary of an industry-wide effort that failed? And the presentation cited SMTP Mail From, as if that were the important field to protect. (And it doesn't even mention DKIM.) Also, the researchers appear not to know about the issue of co-variates. (eg, 21% of their subjects had graduate degrees...) And, for the current discussion, there's the troublesome summary the they give about their own study: 1. Warning only slightly lowers the click rate 2. The absolute click rate is still high The key words there are "slightly" and "still high". Prompting the question of why anyone would think this study serves as demonstrating strong support for the role of end-users in abuse protection? All of which demonstrates a basic problem with efforts to discuss human-related work: difficulties in understanding how to evaluate research and research patterns, with a tendency to instead lean on confirmation bias. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field
The problems with your proposal have been well documented, but you apparently choose not to hear. The single paragraph that Scott quoted has multiple problems within it. The group has considered other and better technical proposals (conditional signatures, ATSP, RHSWL), but they have all been dropped because the group did not believe that Domain Owners would have any desire to implement them, and because Mailing List Operators would have no way of knowing which mailing lists had implemented the new feature. If you have solutions to these problems, please put them forward. Otherwise, why are we dragging this back up? From: Dave Crocker Sent: 9/25/20 11:04 PM To: Scott Kitterman Cc: IETF DMARC WG Subject: Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field On 9/25/2020 4:21 PM, Scott Kitterman wrote:On Friday, September 25, 2020 7:05:22 PM EDT Dave Crocker wrote:I think the obligation to justify is on the advocate for change. That means you are demanding I prove negative. Which, of course, is an impossible assignment. Rather, the obligation is on the person claiming the affirmative, which in this case means the claim that this proposal somehow 'breaks' or otherwise hurts DMARC. Because the current email protection behavior involves the RFC5322.From field, and pertain to the human author, it is common to think that the issue, in protecting the field's content, is behavior of the human recipient. However there is no indication that the enforced values in the RFC5322.From field alter end-user behavior. In fact there is a long train of indication that it does not. Rather, the meaningful protections actually operate at the level of the receiving system's mail filtering engine, which decides on the dispostion of received mail. Please provide references for your long train of indications, speaking of making overly broad assumptions. If that's accurate, I'd like to understand the data that tells us that. I'm not going to do that, because there's a long history of that work being ignored, in spite of it being reviewed repeatedly in thse and related fora over the years. It's gotten tiresome to have people claiming an effect that they lacks evidence for, and the data to the contrary that they are somehow unaware of. Again, the real requirement is focus on the affirmative. In this case, an affirmative claim that end-users are relevant to the efficacy of DMARC. I don't recall seeing any research results validating such a view, but perhaps I missed it. Well, ok, here's one that shows lack of efficacy, and it's a big one: EV-certs Google to bury indicator for Extended Validation certs in Chrome because users barely took notice https://www.theregister.com/2019/08/12/google_chrome_extended_validation_certificates/ "The reason is simple. "Through our own research as well as a survey of prior academic work, the Chrome Security UX team has determined that the EV UI does not protect users as intended... users do not appear to make secure choice..." If this is just an input into an algorithm, then your assertion that you are only providing another input is supportable, but that's contrary to the DMARC design. Perhaps you have not noticed but the demonstrated field use of DMARC, to date, tends to be contrary to the design, to the extent anyone thinks that the design carries a mandate that receivers follow the directives of the domain owners. So the text in the draft merely reflects real-world operational style. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field
On Sat 26/Sep/2020 05:03:51 +0200 Dave Crocker wrote: > On 9/25/2020 4:21 PM, Scott Kitterman wrote: > > Well, ok, here's one that shows lack of efficacy, and it's a big one: EV-certs > > /Google to bury indicator for Extended Validation certs in Chrome because > users > barely took notice/ > > https://www.theregister.com/2019/08/12/google_chrome_extended_validation_certificates/ > > > > "The reason is simple. "Through our own research as well as a survey of prior > academic work, the Chrome Security UX team has determined that the EV UI does > not protect users as intended... users do not appear to make secure choice..." A pointer to a better aimed report circulated on this list: *End-to-End Measurements of Email Spoofing Attacks* https://www.usenix.org/conference/usenixsecurity18/presentation/hu They say: Our phishing experiment shows that security indicators have a positive impact on reducing risky user actions, but cannot eliminate the risk. >> If this is just an input into an algorithm, then your assertion that you are >> only providing another input is supportable, but that's contrary to the DMARC >> design. > > Perhaps you have not noticed but the demonstrated field use of DMARC, to > date, > tends to be contrary to the design, to the extent anyone thinks that the > design > carries a mandate that receivers follow the directives of the domain owners. Some organizations are very careful at setting DMARC policies. Paypal is a classic example, as they don't allow protected transactional domains to be casually used by humans. Such organizations need to be able to explicitly opt out of the Sender experiment. Other organizations may want to opt in, possibly allowing a limited class of mediators. The real word bond is something along the lines of /I tell you how to discard phishing, how you protect your users is up to you/. Some receivers focus more on MTA filtering, other focus on security indicators. Both actions depend on the DMARC policy published at the From: domain. If the From: domain participates in the Sender experiment, then the policy at Sender: may be relevant as well. Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
