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 > <[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]
