Re: [dmarc-ietf] Ticket #55 - Clarify legal and privacy implications of failure reports

[Alessandro Vesely <[e-mail]>]

On Tue 22/Dec/2020 20:41:06 +0100 Michael Thomas wrote:
> On 12/22/20 10:59 AM, Alessandro Vesely wrote:
>>
>>> Sorry, having to ask for permission because of laws does not constitute a 
>>> "severe privacy concern".
>>
>> Except in the sense that they're called privacy laws.  Do you have a better 
>> wording?
>
> I don't know what was wrong with the initial text. But it most certainly is not 
> a "severe privacy concern", especially if it is the originating domain getting 
> the report. It already saw the original message in the first place assuming it 
> wasn't spoofed, and if it was spoofed they are entitled to see it for forensics 
> if the receiving domain is willing to send it to them.


It may happen that the ruf= address ends up at the same submission server that 
issued the original message, but that's not guaranteed.  John mentioned a real 
example.


>>> That is completely outside of the scope of IETF and we should be pandering 
>>> to it.
>>
>> Making specifications that cannot be legally abided by is in IETF scope?
>
> If the laws are unreasonable? Sure. We're not putting backdoors in for 
> encryption either. It's their laws, let them figure it out.


Failure reporting is rather akin to backdoors, in the sense that it can be used 
for pervasive monitoring.  IMHO, GDPR is long winded and lacks practical design 
elements that could have inspired privacy-protecting protocols, but its intent 
is certainly not unreasonable.


> But you said that providers can get people to opt in, so that seem moot.


I'd recommend that software implements failure reporting, leaving it disabled 
with the possibility to enable it by domain in case of need.  However, such 
recommendation would be an addition to the protocol, so it is not going to make 
it to the spec.


Best
Ale
--