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

[Alessandro Vesely <[e-mail]>]

On Fri 11/Dec/2020 18:24:16 +0100 Jesse Thompson wrote:
> On 12/11/20 7:48 AM, Alessandro Vesely wrote:
>> On Thu 10/Dec/2020 17:59:54 +0100 Jesse Thompson wrote:
>>> On 12/9/20 10:28 PM, seth wrote:
>>>> 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.
>>>
>>> To be clear, I'm not advocating for this From/To use case, but I know of universities who would.  There's at least one who cleverly flattened their SPF record to include every known sender specifically because they had no mission to change the way their institution distributively sends email.  That is the type of organization who *may* want From/To data, assuming they want to do more validation before adding yet another IP to their SPF.  It's a stretch in my mind.
>> 
>> I'm not clear whether you're talking about sending or receiving reports.  Received: chains are key for evaluating addresses to add to SPF records.  I don't think it makes sense to specify their omission from 
> 
> Only the last hop from the receiver's viewpoint is really needed for a domain owner to assess gaps in SPF.  That's already addressed with aggregate reports.  What's missing is the additional context that the failure reports are intended to provide, to help domain owners determine if the IP address which sent the message was legitimate.  Of course, received chains are helpful for troubleshooting.  There's no "right" answer regarding the balance of useful information vs privacy, so I'm suggesting that we put things like this on a spectrum of usefulness/privacy-concerning.


Thus far, the spec doesn't discuss what to redact, except for mentioning local 
parts of email addresses.


>> My guess at why an organization may want to send only From/To rather than a possibly redacted text/rfc822-headers are as follows:
>> 
>> * It is too hard for them to asses the risk of including unknown header fields, yet they must do it before enabling ruf,
>> 
>> * the software they use doesn't have an option to redact PII, or (unlikely)
>> 
>> * they try to save bandwidth and disk space by reducing that ghastly pile of freaky fields that infest message headers these days.
> 
> If sending only a limited amount of information is considered an acceptable alternative to full/unredacted information, it might help encourage these organizations to send failure reports, perhaps?


I'm surprised that the request in this ticket proposes to send only the two 
most sensitive fields.


Best
Ale
--