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

Alessandro Vesely <vesely@tana.it> Tue, 02 February 2021 11:40 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 AFAA23A19C9 for <dmarc@ietfa.amsl.com>; Tue, 2 Feb 2021 03:40:13 -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 ohhqLPHmb4La for <dmarc@ietfa.amsl.com>; Tue, 2 Feb 2021 03:40:11 -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 EA4B13A19C8 for <dmarc@ietf.org>; Tue, 2 Feb 2021 03:40:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1612266008; bh=i9dI18J7hniF3QfpmnYa9lQsFw/TEoniheOUYX9qipk=; l=1279; h=To:References:From:Date:In-Reply-To; b=CATrFCkK0+yXMRJYe2i/iJtyFvO3Yx2e2PrUxBE4g3hhK4vu0+cdhjid0+uucrYwG gFJp3+raIDQmZv0WTN1GCW+PgpIn/MhH6p33rL5rRQul+mOGDJo/8jWAW9+hCJndjY jkJKCN9D7tntMzIH6psljLauz2NESnn8x/AyVn2RU8r6gHs7VL3HljQf1qusZ
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 00000000005DC083.0000000060193A18.00001C8F; Tue, 02 Feb 2021 12:40:08 +0100
To: John R Levine <johnl@taugh.com>, dmarc@ietf.org
References: <20210131200238.931356D11D79@ary.qy> <e7e27e1f-b6e6-96b6-e12e-672084562b8a@tana.it> <41bc91e9-8c9a-e2bd-a351-602436f3f5bb@taugh.com>
From: Alessandro Vesely <vesely@tana.it>
Message-ID: <14646a55-66a6-974e-baf8-55d8503c4f96@tana.it>
Date: Tue, 2 Feb 2021 12:40:07 +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: <41bc91e9-8c9a-e2bd-a351-602436f3f5bb@taugh.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/aQQCrCV0tKKxViK1KcNhYcG5mqE>
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: Tue, 02 Feb 2021 11:40:14 -0000

On Mon 01/Feb/2021 17:29:23 +0100 John R Levine wrote:
>> 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?
> 
> You might have other ways to prevent mailbombing, e.g., only sending failure 
> reports to people who you know have bigger mail systems than you do.


Right.  However, Murray recalled Section 6.3 of SMTP:

                           Whatever mechanisms are used, servers MUST
    contain provisions for detecting and stopping trivial loops.


Mailbombing in general is not a loop.  Two report generators reporting each 
other's failure to authenticate a failure report /is/ a loop.  So it deserves a 
MUST.  Perhaps:

    Reporters SHOULD rate limit the number of failure reports sent to any
    recipient to avoid overloading recipient systems.  In addition,
    reporters MUST ensure that such rate limiting or any other means
    can effectively stop possible mail loops.

?



Best
Ale
--