On Fri, Jun 27, 2025 at 7:06 PM Dotzero <dotz...@gmail.com> 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. ;-) 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? > 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. -MSK
_______________________________________________ dmarc mailing list -- dmarc@ietf.org To unsubscribe send an email to dmarc-le...@ietf.org
