Hi Murray and DMARC, This is to acknowledge your message and the end of this call for consensus.
Thanks to Barry for formulating the three options and giving structure to the discussion. When I have completed my evaluation, I will send a message to this list. -andy, ART AD On 3/31/25 10:36, Murray S. Kucherawy wrote:
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 <[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 <[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 <http://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]
