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 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. > 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? Best Ale -- _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
