Re: [dmarc-ietf] Ticket #61 - Define and add a simplified (redacted) failure report

[Seth Blank <[e-mail]>]

On Wed, Dec 9, 2020 at 8:19 PM Murray S. Kucherawy <[e-mail]>
wrote:

> On Wed, Dec 9, 2020 at 1:29 PM Brandon Long <blong=
> [e-mail]> wrote:
>
>> In today's much more privacy conscious world, should we have RUF reports
>> in DMARC
>> at all?
>>
>
> Forensic reports in DMARC are akin to the DKIM failure reporting we added
> to ARF back in the MARF working group.  In fact if you go back and read
> those RFCs, an ancestor to the "pct=" tag is there. (RFC 6591 and RFC 6651
> in particular are what I'm looking at.)
>
> Back in the original DKIM era I always found this kind of reporting to be
> really valuable especially since DKIM can fail for a variety of reasons
> that are far less obvious than SPF.  Being able to get the verifier to tell
> me exactly what it saw and compare it to what I think I sent was key to
> getting the implementation right especially in curious corner cases (any of
> you that remember the DKIM interop event would know what I mean).
>

> Seems to me that's still a useful thing to have, at least sometimes.  We
> might say something like: Include support for this, but don't have it on by
> default.  Or even if it's an extension to DMARC and not part of the base
> protocol, it might be really helpful in some situations.
>

Speaking as a report processor, never in all my years of helping domain
owners use dmarc reports to authenticate their mail has this ever been
necessary.

As an individual, I feel extremely strongly that failure reports should go
away in their entirety. Although Jesse Thompson has outlined a use case
that really has no other good solution, and is equally true in other large
complicated organizations. However, this problem is mitigated with a tree
walk, where you can get the reports to the appropriately localized part of
the organization (like, math.wisc.edu, instead of to Jesse at wisc.edu
who'd need to hunt things down).

As Chair, I've seen relatively strong opinions that people wish for failure
reports to remain. More conversation here is useful.

For this ticket in particular-- the simplified failure report with only
from: and to: addresses speaks to Jesse's exact use case, without any of
the other PII that tends to get failure reports in privacy trouble (like
body content and attachments). This approach to Jesse's use case should get
a fair discussion, separate from whether we want failure reports at all.

Seth

-- 

*Seth Blank* | VP, Standards and New Technologies
*e:* [e-mail]
*p:* 415.273.8818


This email and all data transmitted with it contains confidential and/or
proprietary information intended solely for the use of individual(s)
authorized to receive it. If you are not an intended and authorized
recipient you are hereby notified of any use, disclosure, copying or
distribution of the information included in this transmission is prohibited
and may be unlawful. Please immediately notify the sender by replying to
this email and then delete it from your system.