Re: [dmarc-ietf] DMARCbis Privacy Considerations was: Re: I-D Action: draft-ietf-dmarc-dmarcbis-17.txt

[Alessandro Vesely <[e-mail]>]

On Tue 30/Aug/2022 23:34:18 +0200 Scott Kitterman wrote:
> On Monday, August 29, 2022 12:27:11 PM EDT Scott Kitterman wrote:
>> 
>> RFC 9091 Privacy Considerations (which are currently incorporated by 
>> reference in DMARCbis) say that for PSDs, feedback MUST be limited to 
>> Aggregate Reports.
>>
>> I think it would be appropriate that DMARCbis have a short Privacy 
>> Considerations section which points out that putting an rua or ruf tag in 
>> your DMARC record may have privacy implications for organizations with 
>> pointers to the reporting drafts for details.  I would include something 
>> like if psd=y, MUST NOT also have an ruf= value in DMARCbis.


I oppose that point, as explained below.


> I've prepared an update in git (that I will shortly submit as a PR).  The 
> bulk of it is to add a new Privacy Considerations section.  That's provided 
> below. > [...]
> ## Failure Report Considerations {#failure-report-considerations}
> 
> Failure reports do provide insight into email sending patterns, including
> specific users.  If requesting failure reports, data management controls
> are needed to support appropriate management of this information.  The
> additional detail available through failure reports (relative to aggregate
> reports) can drive a need for additional controls.  As an example, a
> company may be legally restricted from receiving data related to a specific
> subsidiary.  Before requesting failure reports, any such data spillage risks
> have to be addressed through data management controls or publishing DMARC
> records for relevant sub-domains to prevent reporting on data related to
> their emails.
> 
> Out of band agreements between failure report senders and receivers may be
> required to address privacy concerns.
> 
> DMARC records for multi-organizational PSDs MUST NOT include the ruf= tag.


Dmarcbis allows PSDs to send messages.  Indeed the tree walk sections provide 
for cases where the first domain searched has psd=y.  PSDs should be able to 
get failure reports for the messages they send.  Publishing a ruf= tag is key 
to having a chance to get them.

The privacy consideration should prevent report generators from /sending/ 
failure reports for messages that were sent from a child domain of a PSD.  That 
is, an authentication failure in a message where the org domain is determined 
to be PSD+1 and the policy record is the PSD (because the org domain publishes 
no DMARC record) MUST NOT be reported.


Best
Ale
--