This thread seems to have died down. Andy, I think we're looking to you for a consensus call here.
-MSK On Sun, Mar 23, 2025 at 3:07 PM Marc Bradshaw <marc= [email protected]> wrote: > I concur with option 3, for the reasons noted by Todd. They represent a > privacy issue and have not been implemented at scale thus far. > > On Thu, 20 Mar 2025, at 12:12 AM, Todd Herr wrote: > > > > On Wed, Mar 19, 2025 at 8:52 AM Mark Alley <mark.alley= > [email protected]> wrote: > > > On 3/19/2025 7:03 AM, Dotzero wrote: > > On Wed, Mar 19, 2025 at 7:09 AM Barry Leiba <[email protected]> > wrote: > > I note that we are shutting down the DMARC working group without > completing the failure reporting document. We have discussed what to do > about failure reporting,but never made a decision. We need to decide now. > > I see three options: > > 1. Continue discussing the document, complete it, and ask Andy to > AD-sponsor it. > > 2. Abandon the document, leave failure reporting as it had been, and refer > people to the old (Informational) DMARC spec for documentation of it. > > 3. Abandon the document and deprecate failure reporting. That would > involve mentioning failure reports, noting that they have been seldom used > and problematic, and stating that their use going forward is not > recommended. > > I recommend that we do (3), and call for objections to that path. If you > agree with (3), please note that here. If you prefer (1) or (2), please > state that and say why. If you see another reasonable option and prefer > it, please describe it. > > Please post your opinion by the end of March. > > I’ll note that options 2 and 3 require adjustments to the approved drafts, > and will need Andy’s review and approval for the changes. > > Barry > > > As one of the people who originally came up with DMARC, I strongly > disagree with approach 3. We could have kept DMARC a "private club" that > created value only for those invited to participate. Instead the > participants in the effort felt that the value created should be publicly > available to everyone through a public standards effort and that IETF was > the natural place for such an effort. Failure Reports are part of that > value proposition. They are currently being provided today but > privately.,as a result of privacy and liability concerns stemming from > various regulatory frameworks from governmental bodies. > The real question we should be trying to answer is whether or not > provision of Failure Reports should be kept a public documented standard or > recede back to a private club monetized by 3rd party intermediaries with no > hope of it returning to be an open public standard. The question as laid > out by Barry is strictly procedural without regard to whether there is > value in keeping Failure Reports a public open standard. I appreciate that > the DMARCbis effort has been long and arduous. People are tired. If option > 3 is chosen, Failure Reports won't go away. Their form and function will > simply become controlled by a handful of large players. There is also the > risk of divirging format and implementations if individual large players > look to their own interests. Ultimately, option 3 is a bad choice when > considering the interests of the community at large and open standards.. > While I prefer option 1, I can reluctantly accept option 2 as it allows " > a second bite of the apple" at a later point if the IETF email community > decides to take up the effort at a later point..We are so close. Let's > complete the journey we started. > Michael Hammer > > _____ > > +1 to the points and preferences raised here. > > > > I favor option 3, for the following reasons: > > First, it is my belief that failure reports represent an untenable risk of > exposure of PII, especially in the scenario where bad actor A spoofs brand > B in a message to C, where C is not a customer of B and B has no > relationship with C. A failure report sent to B under this circumstance by > C's mailbox provider therefore risks exposing C's PII to B. > > Now, because of the risk of PII exposure, those few providers that still > do send failure reports heavily redact them, which in my view makes them > all but useless for either purpose for which they were originally designed. > They cannot be used for proper troubleshooting of failed authentication of > mail that was authorized by the Domain Owner and they don't provide enough > actionable evidence for any abuse desk or takedown vendor to use to try to > stop fraudulent use of the domain. > > In my opinion, failure reports were a great idea when DMARC was conceived, > but many years of experience should teach us that their time has passed. > > > -- > Todd Herr > Some Guy in VA LLC > [email protected] > 703-220-4153 > Book Time With Me: https://calendar.app.google/tGDuDzbThBdTp3Wx8 > _______________________________________________ > dmarc mailing list -- [email protected] > To unsubscribe send an email to [email protected] > > > -- > > Marc Bradshaw > marcbradshaw.net > > > _______________________________________________ > dmarc mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ dmarc mailing list -- [email protected] To unsubscribe send an email to [email protected]
