Re: [dmarc-ietf] Recipient domain in aggregate reports (#62)

Alessandro Vesely <vesely@tana.it> Mon, 10 May 2021 16:01 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 764D13A21EC for <dmarc@ietfa.amsl.com>; Mon, 10 May 2021 09:01:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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.001, RCVD_IN_MSPIKE_WL=0.001, 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 ShnR7gjId5Zc for <dmarc@ietfa.amsl.com>; Mon, 10 May 2021 09:01:48 -0700 (PDT)
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 354523A21F7 for <dmarc@ietf.org>; Mon, 10 May 2021 09:01:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1620662501; bh=8L/mdx+vholdKnUvmo/yvGWuesUSbEsPFjc3t7j4UzI=; l=1675; h=To:Cc:References:From:Date:In-Reply-To; b=DZ2tNUXtO74TTFX5zaZ/tSFd9gPwj/VCJBlTZCjS04Rr1Nm1USZbPi4xbAjBFkSRB snJ//aOzQrGoJm4dXXpWQD1Mgb6woIU746+rC6Q1A8bLi/qpIGHhC0jPN3bYC5LWTI 3Ec4oDF5S49KgAafXDRjcB1qLOXcvVjL9SiadMOgKe6oCFdw2X9oDZ9iLmHhO
Authentication-Results: tana.it; auth=pass (details omitted)
Original-From: Alessandro Vesely <vesely@tana.it>
Original-Cc: superuser@gmail.com
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 00000000005DC0CC.00000000609958E5.00001FC8; Mon, 10 May 2021 18:01:41 +0200
To: John Levine <johnl@taugh.com>, dmarc@ietf.org
Cc: superuser@gmail.com
References: <20210508185117.5F43D72D3A7@ary.qy>
From: Alessandro Vesely <vesely@tana.it>
Message-ID: <016546b8-3b23-4059-0ae9-530bfb75e2d5@tana.it>
Date: Mon, 10 May 2021 18:01:41 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.9.0
MIME-Version: 1.0
In-Reply-To: <20210508185117.5F43D72D3A7@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/0hxt1QJ4vUNW1Jf8M72YbJNcN0U>
Subject: Re: [dmarc-ietf] Recipient domain in aggregate reports (#62)
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, 10 May 2021 16:01:59 -0000

NOTE: adjusted ticket number, #23 to #62

On Sat 08/May/2021 20:51:15 +0200 John Levine wrote:
> It appears that Murray S. Kucherawy  <superuser@gmail.com> said:
>> Personally, I think mandatory reporting wouldn't survive Last Call or IESG
>> Evaluation.  Even if it did, there's no mechanism to enforce it ...
> 
> Indeed.  I check DMARC on all my incoming mail, but it is unlikely
> that I will ever get around to sending reports.


It'd be interesting to know what refrains you to do DMARC aggregate reports.

For the opposite POV, I can say I generate these reports because they make an 
interesting, albeit partial, view of my incoming mail traffic.  Then, among the 
silly reasons why I send them:

* I don't think any PII leaks out that way,
* the spirit of global community suggests helping peers is a Good Thing,
* outgoing reports constitute a relevant part of my nanoscopic outgoing 
traffic, so they help keep my IP warm.


> More to the point, IETF standards tell people what to do if you want
> to interoperate, not how the document's authors might wish the world
> were different. You can obviously implement all of DMARC processing on
> inbound mail without ever sending a report, so in this place MUST is
> simply wrong.


Agreed, SHOULD seems to be the right world here.  I'd expect your reply to the 
above question to provide subject matter for the reasons why an operator may 
want to not do it.  In addition, there could be reasons for not sending a 
specific aggregate report, such as locally imposed or remotely requested size 
limits, and local policy about the target domain, its IP(s), country, or whatever.


Best
Ale
--