Re: [dmarc-ietf] Report bombing is a prolem, Forensic report loops are not

Alessandro Vesely <vesely@tana.it> Mon, 01 February 2021 12:32 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 11E7B3A10E7 for <dmarc@ietfa.amsl.com>; Mon, 1 Feb 2021 04:32:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.121
X-Spam-Level:
X-Spam-Status: No, score=-2.121 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.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 tOJ9QkyWCYuq for <dmarc@ietfa.amsl.com>; Mon, 1 Feb 2021 04:32:13 -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 82EF43A10E6 for <dmarc@ietf.org>; Mon, 1 Feb 2021 04:32:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1612182730; bh=mC4uDVnSHH6RXlxZG1LUJ8SEP3AYz8w2fAvopj1Pjp4=; l=1403; h=To:References:From:Date:In-Reply-To; b=A9Yi0mdGyyJiHx2KGvx4I3htWVDS6qcCEYdYVS/1XWW4VS4Te2IiXaVAJ39jyqPyh wJ/PRDXok4ExDXgLFobYQ3gBlgKMpG0+e5v5jwcs+lqA6N5LzKbZN5bZovmnnTgFKc cZzTgHvap1PmXpMLXB9NdbdvJvYuA5tuo7cW1N1M1NVf45sU/JSg6Njx9oXEV
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 00000000005DC028.000000006017F4CA.00001EF4; Mon, 01 Feb 2021 13:32:10 +0100
To: John Levine <johnl@taugh.com>, dmarc@ietf.org
References: <20210131200238.931356D11D79@ary.qy>
From: Alessandro Vesely <vesely@tana.it>
Message-ID: <e7e27e1f-b6e6-96b6-e12e-672084562b8a@tana.it>
Date: Mon, 01 Feb 2021 13:32:10 +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: <20210131200238.931356D11D79@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/-x3JwSPLwbcyUAle-THvBluwwzU>
Subject: Re: [dmarc-ietf] Report bombing is a prolem, Forensic report loops are not
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, 01 Feb 2021 12:32:15 -0000

On Sun 31/Jan/2021 21:02:38 +0100 John Levine wrote:
> In article <49b248dc-91a7-7f2d-ba28-72fe8d6d356a@tana.it> you write:
>>Rate limiting usually implies a number of buckets.  They are managed by 
>>imposing limits per time periods, which can be either server-global or per 
>>bucket.  Normally, for MSA usage, one has one bucket per user.  I have never 
>>implemented failure reporting, but I'd guess buckets may vary.  Besides the 
>>signing domain (which determines the report consumer), the receiving address, 
>>the sender and the spam flag may deserve their own buckets.
> 
> The only one that matters for DMARC reporting is the recipient
> address, since the purpose of rate limiting is to avoid overloading
> the recipient mail system. I wouldn't worry about trying to send a
> "representative" set of reports.
> 
> Keep in mind that very few people send failure reports at all.


True, it's not worth suggesting a super duper rate limiting.

Committed text:


3.3.  Transport

    Email streams carrying DMARC failure reports MUST conform to the
    DMARC mechanism, thereby resulting in an aligned "pass".  Special
    care must be taken of authentication, as failure to authenticate
    failure reports may result in mail loops.

    Reporters SHOULD rate limit the number of failure reports sent to any
    recipient to avoid overloading recipient systems.


Not MUST?

Best
Ale
--