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. > 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 would only strongly advocate for seeing the unredacted From header, since >> my primary concern was with identifying a little bit more information about >> who was using the domain and why (i.e. who is using random ESP). > > > Agreed. > > >> The stated purpose of Failure Reports is "for quickly notifying the Domain >> Owners when there is an authentication failure ... also provide more >> information about the failed message than is available in an aggregate >> report". Since the focus of DMARC is to authorize the use of the domain >> used in the From header, then the logical next incremental levels of "more >> information" should be: >> >> 1) From header domain (already known) >> 2) local part of From address >> 3) Friendly From >> 4) Subject >> 5) other parts of the message containing identifiable information >> >> 1->5 decreases in usefulness/relevancy to DMARC >> 1->5 increases in unnecessary information disclosure > > > The mail filter I do sends aggregate reports but not failure reports. Should > I add it? I'm thinking I could frame it like so: > > * Have a global flag to enable or disable ruf's, which can be overridden on a > per-domain basis. Default to disabled. > > * The flag can specify three confidentiality levels: > - full message > - header only > - header only + redact. > > * Redacting the header would work as follows: > 1. Collect recipients addresses in To:, Cc:, and envelope, > 2. compute the rfc6590-redacted version of each address, > 3. for all fields, replace any occurrence with the redacted version. > > * Reports are left in a user-configured directory, assuming that a user > supplied script deals with them. > > Does that make sense? > > Should dmarc-failure-reporting include text with practical suggestions along > those lines? Does this redaction logic apply to the From header too? If so, I would recommend adding a fourth confidentiality flag for reporters who want to redact recipient information but leave the From header unredacted to better aid the domain owner in tracking down the sender. Jesse _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
