On Mon, Jun 30, 2025 at 2:45 PM Murray S. Kucherawy <[email protected]> wrote:
> On Fri, Jun 27, 2025 at 7:06 PM Dotzero <[email protected]> wrote: > >> ] would suggest that you are a bit presumptuous in claiming to know what >> was or wasn't the original intended purpose of DMARC and reporting seeing >> as you weren't part of the group of people that came up with DMARC. We knew >> early on, well before it was submitted to IETF, that RUF reports are >> extremely useful for addressing abuse. >> > > Wait, were you part of MOOCOW? That's not how I remember it. ;-) > MOOCOW != DMARC. When J.D. asked me to participate in MOOCOW, I took a pass because I felt it would fail.(I was right). Work on this (in private) was taking place well before MOOCOW was a gleam in J.D.s eye.Here is a paragraph from an email to that group from someone about my proposal for a reporting FBLin this space. The email is dated June 17th, 2008: " > A key new idea is being floated by Michael Hammer, it's not in the attached > draft. The idea is to include a header in all email going out of a domain. > The header would indicate that the receiver should check for the presence > of a feedback loop advertisement TXT record ("_feedback.domain.com")." This was later modified to it's present form with the standard DMARC record that included the information for reporting requests.. > > I was one of the advocates for failure reporting in the original work, > because I had found it so useful in DKIM especially during interoperability > testing. As a result I incorporated what became RFC 6651 into DMARC to > produce the failure reports in RFC 7489. OpenDMARC is able to generate > both failure and aggregate reports as a result. I have no data, > however, how many people have enabled either, or who may have used it > (besides me) in OpenDKIM. > > RUF may not be useful to you but it is useful to others. For mail >> originating in complex environments RUF can be very useful. For example, >> I've seen mail DKIM signed by a mail server and then the signature is >> broken by another server at the edge. Another example is a mail server DKIM >> signing with broken signatures but it is one of a number of servers (the >> others signing correctly) in an outbound VIP on a load balancer. >> > > Wouldn't DKIM error detection satisfy the need in this situation? Why do > we need failure reporting at both levels? > DMARC still includes SPF. Why would you include failure reporting for one class of failure (DKIM) and not the other (SPF)? Illogical. > > >> In summary, RUF reporting can be useful for both troubleshooting problems >> with ones mail flows AND for fighting abuse. The fact that you personally >> don't receive many and don't find the little you receive useful .cannot be >> extrapolated to the universe of use cases. >> > > Who might we ask to get anecdotal evidence that they're useful and ought > to be preserved? A theoretical existence proof shouldn't be the basis for > us making this decision. > I gave my anecdotal "evidence" that covers using the reports for at a minimum 10s of thousands of takedowns/antiabuse. I can't provide specific data/numbers as I no longer work for that organization and the data isn't mine. As far as me using DMARC reporting for failures, I would be a bad example. By the time we finalized DMARC (before sending it to IETF, my sending implementation (both SPF and DKIM) was clean and we were seeing only transient errors through reporting. Various large mailbox providers used our sending implementation DKIM signing/SPF to test their validation implementations.Just as an aside, in the very early days, several of these large mailbox providers were sending me extracts from their logs so we had a common basis to discuss any errors. Michael Hammer
_______________________________________________ dmarc mailing list -- [email protected] To unsubscribe send an email to [email protected]
