Re: [dmarc-discuss] Blind RUF and GDPR (Re: RUA vs RUF reports)
On 31/05/18 10:28, Richard via dmarc-discuss wrote: Date: Thursday, May 31, 2018 09:26:38 +0800 From: Roland Turner via dmarc-discuss Sending failure reports to strangers appears unjustifiable under GDPR. A currently common case where reports are going where they shouldn't is with mailing lists. If a list (that doesn't do rewrites) receives a message purportedly from say yahoo (which is set to p=reject), mail to every list member whose ESP enforces dmarc will cause a bounce/reject potentially causing a failure report to be sent. These list members have no relationship with yahoo, save that they are on a list that someone sent to using a yahoo address, and have no control over the list or ESP configuration. I can't think of a legitimate reason for yahoo to get these reports. Ongoing visibility of the impact of their p=reject decision seems reasonable, although that could readily be obtained from aggregate reports (and indeed more accurately, as more organisations send them). Interdicting phishing is not relevant (where it might be if the address were @paypal.com). Even understanding the mechanism of selected failures seems a fairly weak interest, and one that could be better pursued with private channels rather than ruf=. Interesting. - Roland ___ dmarc-discuss mailing list dmarc-discuss@dmarc.org http://www.dmarc.org/mailman/listinfo/dmarc-discuss NOTE: Participating in this list means you agree to the DMARC Note Well terms (http://www.dmarc.org/note_well.html)
Re: [dmarc-discuss] Blind RUF and GDPR (Re: RUA vs RUF reports)
> Date: Thursday, May 31, 2018 09:26:38 +0800
> From: Roland Turner via dmarc-discuss
>
> On 31/05/18 04:51, Jonathan Kamens via dmarc-discuss wrote:
>
>> On 5/30/18 4:22 PM, John Levine wrote:
2) The people receiving the failure reports aren't "total
strangers." They are either (a) the same people who run the
email infrastructure (if failure reports are handled
internally), who are presumably authorized to look at email
headers while troubleshooting issues, or (b) third-party data
processors (to use the GDPR terminology), which are permitted as
long as how they are using the data is disclosed to users.
>>>
>>> They're sent to whoever some ruf= tag points to. I get all the
>>> failure reports for any message with one of my domains on the
>>> From: line, even if if was forged or a typo or a configuration
>>> error and nobody related to me sent it. Sounds like total
>>> strangers to me.
>>
>> I don't think you can be held responsible if a "total stranger's"
>> email ends up in your inbox because they put your domain in the
>> From line of the email without your authorization. Furthermore,
>> of the cases you mentioned ("forged", "typo", "configuration
>> error"), I don't think anything but "forged" happens with
>> sufficient frequency to be worth your concern or the concern of
>> the European Union's member states' Data Protection Authorities.
>>
>
> This confuses two different "total strangers" cases:
>
> * One is the case where a message ended up somewhere unexpected
> because someone mistyped an email address (whether in a
> message or in a DMARC DNS record).
> * One is where an email receiver is blindly sending failure
> reports to organisations unknown to them.
>
> The former is fine as it stands, so long as the parties involved
> take responsible action with the resulting disclosures (deletion by
> the party who unexpectedly received the data - because continued
> processing, including retention, has no lawful basis - and
> correction of the error by the party who misconfigured a mail
> client, mistyped an address book entry, or mistyped a DMARC DNS
> record).
>
> The latter is the important question. Sending failure reports to
> strangers appears unjustifiable under GDPR.
>
> - Roland
>
A currently common case where reports are going where they shouldn't
is with mailing lists. If a list (that doesn't do rewrites) receives
a message purportedly from say yahoo (which is set to p=reject), mail
to every list member whose ESP enforces dmarc will cause a
bounce/reject potentially causing a failure report to be sent. These
list members have no relationship with yahoo, save that they are on a
list that someone sent to using a yahoo address, and have no control
over the list or ESP configuration. I can't think of a legitimate
reason for yahoo to get these reports.
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss
NOTE: Participating in this list means you agree to the DMARC Note Well terms
(http://www.dmarc.org/note_well.html)
[dmarc-discuss] Blind RUF and GDPR (Re: RUA vs RUF reports)
On 31/05/18 04:51, Jonathan Kamens via dmarc-discuss wrote:
On 5/30/18 4:22 PM, John Levine wrote:
2) The people receiving the failure reports aren't "total strangers."
They are either (a) the same people who run the email infrastructure (if
failure reports are handled internally), who are presumably authorized
to look at email headers while troubleshooting issues, or (b)
third-party data processors (to use the GDPR terminology), which are
permitted as long as how they are using the data is disclosed to users.
They're sent to whoever some ruf= tag points to. I get all the
failure reports for any message with one of my domains on the From:
line, even if if was forged or a typo or a configuration error and
nobody related to me sent it. Sounds like total strangers to me.
I don't think you can be held responsible if a "total stranger's"
email ends up in your inbox because they put your domain in the From
line of the email without your authorization. Furthermore, of the
cases you mentioned ("forged", "typo", "configuration error"), I don't
think anything but "forged" happens with sufficient frequency to be
worth your concern or the concern of the European Union's member
states' Data Protection Authorities.
This confuses two different "total strangers" cases:
* One is the case where a message ended up somewhere unexpected
because someone mistyped an email address (whether in a message or
in a DMARC DNS record).
* One is where an email receiver is blindly sending failure reports to
organisations unknown to them.
The former is fine as it stands, so long as the parties involved take
responsible action with the resulting disclosures (deletion by the party
who unexpectedly received the data - because continued processing,
including retention, has no lawful basis - and correction of the error
by the party who misconfigured a mail client, mistyped an address book
entry, or mistyped a DMARC DNS record).
The latter is the important question. Sending failure reports to
strangers appears unjustifiable under GDPR.
- Roland
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss
NOTE: Participating in this list means you agree to the DMARC Note Well terms
(http://www.dmarc.org/note_well.html)
[dmarc-discuss] Blind RUF and GDPR (Re: RUA vs RUF reports)
On 31/05/18 02:01, Jonathan Kamens via dmarc-discuss wrote: Two comments: 1) Most of the failure reports I've seen haven't included the message body, they've only included the headers. So the exposure is limited. I assume limiting the exposure is the whole reason why the reports don't include message bodies. True, however this seems like a peculiar position. Once you've acknowledged that limiting exposure is important, aggregate reports seem like a more appropriate tool. Note that there is a compelling reason for providing message bodies, arguably the reason for specifying the failure reporting mechanism in the first place, and that's identifying phishing sites to focus deactivation efforts on. Doing this without an NDA would appear problematic. 2) The people receiving the failure reports aren't "total strangers." They are either (a) the same people who run the email infrastructure (if failure reports are handled internally), who are presumably authorized to look at email headers while troubleshooting issues, or No. They are the people who run some other infrastructure. In the "volunteering failure reports without an NDA" case, they are strangers. (b) third-party data processors (to use the GDPR terminology), which are permitted as long as how they are using the data is disclosed to users. I think you're describing intermediaries with whom domain registrants contract to process their DMARC reports. These people are also strangers to the receivers who are sending the reports, unless they have separate agreements with those same intermediaries (most do, at least in the US and EU). Whether or not that they are Data Processors would depend upon the details of those agreements. I've never read one. There /could be/ a GDPR issue if failure reports are sent to a third-party processor /and/ that isn't disclosed to the user, but it isn't /ipso facto/ a GDPR issue to use a third-party processor to manage failure reports. No. Contracting Processors does not require disclosure to Data Subjects; instead contractual arrangements between Controller and Processor to maintain the Data Subject rights and other obligations are required. You're thinking about disclosure to other Controllers. - Roland ___ dmarc-discuss mailing list dmarc-discuss@dmarc.org http://www.dmarc.org/mailman/listinfo/dmarc-discuss NOTE: Participating in this list means you agree to the DMARC Note Well terms (http://www.dmarc.org/note_well.html)
