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

Alessandro Vesely <vesely@tana.it> Mon, 25 January 2021 12:54 UTC

Return-Path: <vesely@tana.it>
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B84DD3A11A2 for <dmarc@ietfa.amsl.com>; Mon, 25 Jan 2021 04:54:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.221
X-Spam-Level:
X-Spam-Status: No, score=-0.221 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1152-bit key) header.d=tana.it
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pt1nubTmqeUO for <dmarc@ietfa.amsl.com>; Mon, 25 Jan 2021 04:53:58 -0800 (PST)
Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B2653A11A1 for <dmarc@ietf.org>; Mon, 25 Jan 2021 04:53:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1611579236; bh=ZwAb9pcW92MlIwVlYud8v1rD1NSmxptqgdPPKyN3jxg=; l=2199; h=To:References:From:Date:In-Reply-To; b=A5GXZdu6TqyKMCq8IqerW7BBVvlGNW+T7mbjNop8Uq+eJ1myHSNUSghEpsOqQoN2K wSco1L7njJtrRbq2gz3K3MwSaBTs4BJWn1RHX6YpGSSGBPhdZNjdB+zRysGjGTBsOi 64SenLXDUncLkccuaksVlBembuodmDZ3AMew1KZDiJNQSiw0DnH3z81tRjgoN
Authentication-Results: tana.it; auth=pass (details omitted)
Original-From: Alessandro Vesely <vesely@tana.it>
Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.3, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC0BB.00000000600EBF64.0000381D; Mon, 25 Jan 2021 13:53:56 +0100
To: John Levine <johnl@taugh.com>, dmarc@ietf.org
References: <20210124184901.10BDD6C0693D@ary.qy>
From: Alessandro Vesely <vesely@tana.it>
Message-ID: <63451726-124b-c24f-3be1-d6435e12c22e@tana.it>
Date: Mon, 25 Jan 2021 13:53:54 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0
MIME-Version: 1.0
In-Reply-To: <20210124184901.10BDD6C0693D@ary.qy>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/X8AdQzplRGy1H5uJtSG9GrhYUwg>
Subject: Re: [dmarc-ietf] Ticket #55, closing
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" <dmarc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmarc>, <mailto:dmarc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dmarc/>
List-Post: <mailto:dmarc@ietf.org>
List-Help: <mailto:dmarc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmarc>, <mailto:dmarc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 25 Jan 2021 12:54:01 -0000

On Sun 24/Jan/2021 19:49:00 +0100 John Levine wrote:
> In article <580831bc-ae5b-de09-e473-39c1a13a8107@tana.it> you write:
>>> 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.
>>
>>
>>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.  [...]
> 
> Why are we telling people to send URIs in preference to any other part
> 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.


>>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 or domain owner.
> 
> Sure, with the correction above.


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

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
--