Re: [dmarc-ietf] PSD Related Privacy Considerations For Aggregate Reporting Draft

[Scott Kitterman <[e-mail]>]

On Tuesday, January 31, 2023 4:06:16 PM EST John R Levine wrote:
> > example, but what matters is really the existence of example.com as I
> > think
> > the purpose is to not leak information to a PSO for a domain that do exist
> > without a DMARC record.
> 
> The ENTIRE POINT of PSD records is to send reports about subdomains that
> exist but don't have their own DMARC records, so the PSD can tell the
> subdomain to fix it.
> 
> The only domains that will ever publish a PSD record are ones like .BANK
> and .INSURANCE that have contracts with their registrants, or like .GOV
> that are effectively a single organization.
> 
> There no chance whatsoever that .COM or any other unrestricted TLD will
> ever publish a PSD record.
> 
> Now that I look at the privacy considerations, we need to rip out stuff
> about Multi-organization PSDs (e.g., ".com") that do not mandate DMARC
> usage because it makes no sense, and the bit about nonexistent only doubly
> makes no sense since it's impossible to implement.

I agree there's no chance a PSD like .com would be authorized to publish a 
DMARC record, but a big part of why is the privacy implications of allowing 
it.  I think we should document the concerns.  ccTLDs will need to develop 
their own policies and we should give them the relevant information to support 
that.

Determining what's a single org PSD, a multi-org PSD, or a multi-org PSD with 
restrictive policies is not something mail receivers can reliably do as part 
of their ongoing operations.  To the extent it's done it needs to be done by 
ICANN (or their ccTLD equivalents) when determining is a PSD should have a 
DMARC record or not.  For a mail receiver I think it's reasonable to assume 
any PSD (psd=y in their record) should be treated conservatively and only send 
reports for non-existent domains.  They might want to take on the technical 
and administrative burden of maintaining their own list of "good" PSDs that 
could get more feedback, but I don't think PSD has broad enough utility to be 
worth the trouble.

I think we have in the drafts is generally complete and correct.  I don't 
think we should reduce the scope of the privacy considerations.  It might make 
sense to be explicit that mail receivers won't be able to tell which kind of 
PSD they are dealing with in real time, so should consider that when 
determining their local policy for feedback based on PSD DMARC records.

Scott K