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

Alessandro Vesely <vesely@tana.it> Sun, 24 January 2021 18:27 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 4BBE13A0F0F for <dmarc@ietfa.amsl.com>; Sun, 24 Jan 2021 10:27:31 -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 7M5tAIc8OzVL for <dmarc@ietfa.amsl.com>; Sun, 24 Jan 2021 10:27:30 -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 F01EC3A0EE6 for <dmarc@ietf.org>; Sun, 24 Jan 2021 10:27:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1611512845; bh=h9aaC+rwpBu5EJbHiZLN1xBYwVleNlFP3nbAnXDW8Ck=; l=1574; h=To:References:From:Date:In-Reply-To; b=Bag5BFwAw7UyTMS/dq6xGqYyzfPDBTbuNHq++2xUgBts/xE7eQCUfUubksHyuBPoW 06uPGiG8f9xFOe2XwlWfK/6DRQqw87xQgLt1Kqymhyu+/RmulbD22s+rF1sOtzGzmj ke6TFxsSBzQ9f+HbjVT2aG798aGiGZbt4Qs03wPVrU/kz9ZLqxZGDPQQ5uvS4
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 00000000005DC0B0.00000000600DBC0D.00000150; Sun, 24 Jan 2021 19:27:25 +0100
To: John Levine <johnl@taugh.com>, dmarc@ietf.org
References: <20210124170505.07A236C05685@ary.qy>
From: Alessandro Vesely <vesely@tana.it>
Message-ID: <580831bc-ae5b-de09-e473-39c1a13a8107@tana.it>
Date: Sun, 24 Jan 2021 19:27:23 +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: <20210124170505.07A236C05685@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/i0SqrZepOLmDh4FJ9wHE2o530KU>
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: Sun, 24 Jan 2021 18:27:31 -0000

On Sun 24/Jan/2021 18:05:03 +0100 John Levine wrote:
> In article <8423eb32-2e45-77d9-dda0-306bacdd4981@tana.it> you write:
>>
>>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
> 
> 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.


That cannot be expressed in the draft itself...


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


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


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