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

[Dotzero <[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.


> Regards,
> John Levine, [e-mail], Taughannock Networks, Trumansburg NY
> Please consider the environment before reading this e-mail. https://jl.ly


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.

In conclusion, suppositional assertions such as " For that reason, and
because it turned out not to be important, failure reporting is usually
disabled." should not be included in the proposed standard. Could someone
(anyone?) provide data that failure reports are not important? One example
of the importance and usefulness of failure reports is for domains that
actually have control of their mail flows. By pulling all the URLs from
failure reports (received through a contracted party) and then removing all
the URLs which we included in the mail that we had originally sent, all
that was left was 100% badness and maliciousness. This significantly
empowered our takedown efforts.

Michael Hammer