This thread is now counterproductive and needs to come to a close. Michael, your continued assertion has been that unauthenticated reports are an issue. But so far no evidence has been presented that reports are sent without authentication, or that the text of the document is the cause.
This thread is going in circles. It's now official CLOSED, unless someone returns with evidence of an actual problem here. Move on to other tickets. Seth, as Chair On Mon, Jan 25, 2021 at 1:55 PM Michael Thomas <m...@mtcc.com> wrote: > > On 1/25/21 1:26 PM, Steven M Jones wrote: > > On 1/25/21 12:18 PM, Michael Thomas wrote: > > > On 1/25/21 12:08 PM, Todd Herr wrote: > > On Mon, Jan 25, 2021 at 2:56 PM Michael Thomas <m...@mtcc.com> wrote: > >> >> Sounds like a bug to me and an issue should be opened. Just because it's >> a 10 year old bug doesn't mean it's not a bug. >> > > I disagree. > > Authentication results should not differ at a given provider based solely > on the destination domain, so there is no reason to report results > separately for each destination domain. Further, there's no value to the > report generators, especially at large sites like Google, to expend the > resources necessary to generate and send X reports when one will do. > > So you're saying I should be free to spoof any domain I want because > Google might be inconvenienced? > > > If the language in 7.2.1.1 that Seth cited is "working," then report > generators are sending reports that pass DMARC and the report receivers are > validating that before ingesting the attached reports. However this only > provides some degree of attribution for the report itself... > > Yes, if that were enforced that would solve the problem. Given the > confusion my guess that it is not. That paragraph could be a lot more > specific about the mechanisms and motivations which I suggested in #98. It > probably requires even more than my suggestion after seeing all of the list > traffic going by. If gsuite is aggregating reports from all of their > domains they host into one report, there is clearly a problem both with the > text and with implementations. > > And of course, any proposed http method would have to provide equivalent > protection. > > Mike > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > -- *Seth Blank* | VP, Standards and New Technologies *e:* s...@valimail.com *p:* 415.273.8818 This email and all data transmitted with it contains confidential and/or proprietary information intended solely for the use of individual(s) authorized to receive it. If you are not an intended and authorized recipient you are hereby notified of any use, disclosure, copying or distribution of the information included in this transmission is prohibited and may be unlawful. Please immediately notify the sender by replying to this email and then delete it from your system.
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
