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

[[e-mail]]

> On Tue, Dec 22, 2020 at 11:39 AM John R Levine <[e-mail]> wrote:

> > I think that text is way too long and overspecific but we've already spent
> > too much time on this so I'll stop and see if there are other opinions.
> >
> >
> > On Tue, 22 Dec 2020, Alessandro Vesely wrote:
> > > OLD
> > >
> > >   "Failure reports," or "failed message reports," provide diagnostic
> > >   information about messages that a Mail Receiver has determined do not
> > >   pass the DMARC mechanism.  These reports are generally sent at the
> > >   time such messages are received and evaluated, to provide the Domain
> > >   Owner with timely notification that such failures are occurring, and
> > >   to provide information that may assist in diagnosing the cause of the
> > >   failures.
> > >
> > >
> > > NEW
> > >
> > >   Failure reports provide detailed information about the failure of a single
> > >   message or a group of similar messages failing for the same reason. They
> > >   are meant to aid extreme cases where a domain owner is unable to detect why
> > >   failures reported in aggregate form did occur.  As an extension of other
> > >   kinds of failure notifications, these reports can contain either the content
> > >   of a failed message or just its header.  The latter characteristic entails
> > >   severe privacy concerns.  For that reason, and because it turned out not to
> > >   be important, failure reporting is usually disabled.

> The following is factually and technically incorrect: " The latter
> characteristic entails severe privacy concerns." The latter characteristic
> "the header". In fact, the full message can contain much more PII and/or
> PHI.

Quite right. It's also unforunate that we appear to be spending more arguing
about what consistutes a legitimate privacy concern than reviewing proposed
text.

I also note that saying what's "usually done", even if currently correct, is at
best the province of a BCP. It has no business being in a standard.

> I agree with John. I'll go further and say that the working group should
> focus on what the IETF does best - technical specifications that involve
> interoperability - and avoid straying too far into the realms of law and
> politics. While the EU and GDPR may impact choices that operators make,
> there are other legal jurisdictions in the world. Further, my experience
> has been that many operators (receivers) only provide failure reports when
> contractual relationships (direct or indirect) exist between the parties
> involved. This can certainly meet the privacy requirements of GDPR and
> other privacy regulations.

Agreed, but none of this belongs in the standard either. All the standard needs
to say is that message header and bodies can contain personally identifiable
information and that this may affect the choice of whether or not to send
failure reports. Something like:

  Failure reports provide detailed information about the failure of a single
  message or a group of similar messages failing for the same reason. They
  are meant to aid in cases where a domain owner is unable to detect why
  failures reported in aggregate form did occur. It is important to note
  these reports can contain either the header or the entire content of a
  failed message, which in turn may contain personally identifiable
  information, which should be considered when decoding whether or not to
  generate such reports.

				Ned