Michael, are you aware of anyone not following the guidance in the document? This thread feels like we're discussing a non-issue. Aggregate reports are already required to be authenticated and I'm unaware of anyone sending failure reports, let along unauthenticated ones. Is the language causing problems? Such problems have not been brought to the list, and would be a good place to start if you want to build consensus.
The list seems to be digging in because no one has raised a use case that shows a need to revisit the text. This was made worse by asserting that reports must be authenticated, when the text already makes that clear. It is likely in scope to discuss if the current text needs to be moved from 7.2.1.1 to 7.1, but let's please be careful to focus on operational feedback and not personal opinions. To be exceedingly clear: if this thread doesn't focus and come to consensus quickly, then ticket #98 should be closed, unless a use case is raised and supported by operational parties, that there is an issue here requiring further clarification. Ticket 99 is still in play, if and only if we decide on adding an HTTPS transport for DMARC reports, of which historical consensus shows this is unlikely. Let's press pause on that until the other discussion is concluded, please. Seth, as chair On Mon, Jan 25, 2021 at 10:00 AM Michael Thomas <m...@mtcc.com> wrote: > Issue #99 would need to be resolved if you want to use https as well. > That's really why I brought up the entire issue. It's an easy fix for > email, and not obvious how you fix it for https. > > Mike > On 1/25/21 9:41 AM, Seth Blank wrote: > > Realized I think we're going in circles. Just posted text that is status > quo that I believe already addresses Michael's concern. > > On Mon, Jan 25, 2021 at 9:38 AM Murray S. Kucherawy <superu...@gmail.com> > wrote: > >> On Mon, Jan 25, 2021 at 9:32 AM Michael Thomas <m...@mtcc.com> wrote: >> >>> Why is this controversial? Seriously. What is controversial about saying >>> that the a report should authenticate? The onus is on the people who say it >>> does not to lay out the case for why it's not a problem, not me. #98 has a >>> simple piece of text to remedy this. it's 2021. You don't use >>> unauthenticated data if you can possibly help it. >>> >> I'm not taking a position at this point on the issue, but I think you >> should expect that this will come up in external reviews. If consensus is >> to maintain the status quo, we might want to say so explicitly (and why) >> rather than saying nothing, as the latter might be interpreted as it having >> gotten no consideration at all. >> >> -MSK >> > > > -- > *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. > > -- *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
