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