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

[Alessandro Vesely <[e-mail]>]

On Thu 10/Dec/2020 05:28:55 +0100 Seth Blank wrote:
> On Wed, Dec 9, 2020 at 8:19 PM Murray S. Kucherawy wrote:
>> On Wed, Dec 9, 2020 at 1:29 PM Brandon Long wrote:
>>
>>> In today's much more privacy conscious world, should we have RUF reports
>>> in DMARC at all?
>>
>> [...]
>> 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.


Can we be explicit about that?  I mean to suggest to develop but not to enable. 
  Furthermore, I'd recommend to develop options to enable failure reports on a 
per-domain basis.  (We could also mention that admins may contact the email in 
the <report_metadata> section of troublesome aggregate reports to ask for 
failure reports to be enabled for their domain for the time necessary to solve 
the problem at hand.)


> As an individual, I feel extremely strongly that failure reports should go
> away in their entirety.


Could we at least limit them to a single, must-be-aligned recipient?


> 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.


I would suggest to redact the local parts of To:, Cc: and similar fields 
(X-Original-To:, Received: for), possibly leaving only the From: intact. 
Delivered-To: should be removed.  The rest of the header can be sent safely, 
methinks.


Best
Ale
--