Subject: [dmarc-ietf] Ticket #55, closing

From: Alessandro Vesely <[email-masked]>
Date: Sun, 24 Jan 2021 12:50:14 +0100

Hi all,

I'm going to post version -01 of failure reporting before 22 February.  Please express consensus or ask for changes.

MD version:
https://github.com/ietf-wg-dmarc/draft-ietf-dmarc-failure-reporting/blob/main/draft-ietf-dmarc-failure-reporting.md

Current diff:
https://tools.ietf.org/rfcdiff?url1=draft-ietf-dmarc-failure-reporting-00&url2=https://raw.githubusercontent.com/ietf-wg-dmarc/draft-ietf-dmarc-failure-reporting/main/draft-ietf-dmarc-failure-reporting-01.txt

Best
Ale
--

---

From: "John Levine" <[email-masked]>
Date: 24 Jan 2021 12:05:03 -0500

>https://github.com/ietf-wg-dmarc/draft-ietf-dmarc-failure-reporting/blob/main/draft-ietf-dmarc-failure-reporting.md

My main concern continues to me that we should not have made this a
separate draft, but we should put all of the reporting in one document.

In sec 3 it says the reports SHOULD include all URIs.  That is a privacy problem since it is common
for unsubscribe URIs to contain the recipient address in plain text or an easily reversed encoding
such as base32.

The privacy considerations miss the fact that organization domains are
only an approximation to actual domain ownership, and reports may be
sent to someone unrelated to the actual sender. This is not
hypothetical; I get reports for subdomains who are not me all the time.

---

From: Alessandro Vesely <[email-masked]>
Date: Sun, 24 Jan 2021 19:27:23 +0100

> separate draft, but we should put all of the reporting in one document.

That cannot be expressed in the draft itself...

> for unsubscribe URIs to contain the recipient address in plain text or an easily reversed encoding

Would something generic as the following do?

    These reports SHOULD include any URI(s) from the message that failed
    authentication, unless privacy reasons suggest otherwise.  [...]

> hypothetical; I get reports for subdomains who are not me all the time.

Shall I add that verbatim as a second paragraph in Security Considerations?

    In addition, note that Organizational Domains are only an approximation
    to actual domain ownership  Therefore, reports may be sent to someone
    unrelated to the actual sender.

Best
Ale
--

---

From: "John Levine" <[email-masked]>
Date: 24 Jan 2021 13:49:00 -0500

>    authentication, unless privacy reasons suggest otherwise.  [...]

Why are we telling people to send URIs in preference to any other part
of the message?  I don't see the point.

>    unrelated to the actual sender or domain owner.

Sure, with the correction above.

R's,
John

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 25 Jan 2021 13:53:54 +0100

> of the message?  I don't see the point.

Dunno.  In draft-kucherawy-dmarc-base-02 the whole paragraph was:

OLDER:
    These reports SHOULD include the "call-to-action" URI(s) from inside
    messages that failed to authenticate.

Gradually, it took the current shape:

OLD:
    These reports SHOULD include any URI(s) from the message that failed
    authentication.  These reports SHOULD include as much of the message
    and message header as is reasonable to support the Domain Owner's
    investigation into what caused the message to fail authentication and
    track down the sender.

Shall we replace it with the following?

NEW:
    These reports SHOULD include as much of the message and message header
    as is reasonable to support the Domain Owner's investigation into what
    caused the message to fail authentication and track down the sender,
    unless privacy reasons suggest otherwise.

> Sure, with the correction above.

I committed both updates in:
https://github.com/ietf-wg-dmarc/draft-ietf-dmarc-failure-reporting

diff:

Best
Ale
--

---

From: "John Levine" <[email-masked]>
Date: 25 Jan 2021 13:01:28 -0500

>    messages that failed to authenticate.

Well, you can guess where that came from.

>    unless privacy reasons suggest otherwise.

I'd strip it down more.

 These reports should include as much of the message header and body as
 possible, consistent with the reporting party's privacy policies, to
 enable the Domain Owner to diagnose the authentication failure.

The "should" is deliberately lower case since it's not something you can
describe mechanically.

R's,
John

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Mon, 25 Jan 2021 10:17:56 -0800

> >    messages that failed to authenticate.

The intent of calling out CTA links was to facilitate takedown efforts
against fraudulent domains rather than being strictly concerned about why
otherwise valid messages failed to authenticate.

--Kurt

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 25 Jan 2021 20:04:27 +0100

> Well, you can guess where that came from.

Should we mention fraudster takedowns among the purpose of failure reports?

>   enable the Domain Owner to diagnose the authentication failure.

committed.

> The "should" is deliberately lower case since it's not something you can

Someone will question it anyway, I'd guess.

Best
Ale
--

---

From: "John R Levine" <[email-masked]>
Date: 25 Jan 2021 14:06:41 -0500

> Should we mention fraudster takedowns among the purpose of failure reports?

Again, seems like mission creep.

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