Re: [dmarc-ietf] Forensic report loops are a problem

Steven M Jones <smj@crash.com> Thu, 28 January 2021 03:17 UTC

Return-Path: <smj@crash.com>
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 67DC73A10CF for <dmarc@ietfa.amsl.com>; Wed, 27 Jan 2021 19:17:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 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, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=crash.com
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 6-rO4PgAVsFM for <dmarc@ietfa.amsl.com>; Wed, 27 Jan 2021 19:17:19 -0800 (PST)
Received: from segv.crash.com (segv.crash.com [IPv6:2001:470:1:1e9::4415]) (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 EFC643A119B for <dmarc@ietf.org>; Wed, 27 Jan 2021 19:17:18 -0800 (PST)
Received: from shiny.crash.com (192-184-141-33.static.sonic.net [192.184.141.33]) (authenticated bits=0) by segv.crash.com (8.15.2/8.15.2/cci-colo-1.7) with ESMTPSA id 10S3H6Ax069709 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for <dmarc@ietf.org>; Thu, 28 Jan 2021 03:17:14 GMT (envelope-from smj@crash.com)
DKIM-Filter: OpenDKIM Filter v2.10.3 segv.crash.com 10S3H6Ax069709
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=crash.com; s=201506-2k; t=1611803836; bh=58KUvoVREoMAfcutyimwxMta+rktYloA+fw5cANlOLQ=; h=Subject:To:References:From:Date:In-Reply-To; b=DAeKbf1xHbV++UoFGUc2PtP3qHCkVqgHdr8C2UeWX6exuM/79VdQ2LHMEj7h136U3 RukkK4ZyyuMskWXqfpIHN2QDaxGixvnsu9VUgUChpwhlrq9DH78L+WNwkRVaCayc9y tHvOZ1nNHofjj5ALr5bDGDAIFuC16YqBrUuM5Qfu7HEppfgLE8HUhaKBWAjYai8seK ve5Po/vL2TKe8vslurD9a1pEH1da6KrWaMknXsBfCeXiuzIb/lKl2uhUGJvMvpPiCC SQLJG9f/pW4mTo1RYL2MeO+QsZaLo/NioKSTMqKDNhQrOg268oUhs5msUlRfefQKNH Efqgg6JQvU+cg==
X-Authentication-Warning: segv.crash.com: Host 192-184-141-33.static.sonic.net [192.184.141.33] claimed to be shiny.crash.com
To: dmarc@ietf.org
References: <CAL0qLwY5BbwvS9XXqBk=Mp074ntN=NeS97pJAxPBdQEZAsgohg@mail.gmail.com> <20210127203714.007C86CDB9CA@ary.qy> <CAL0qLwbN+HkGfvw79rPPvqL6jWWAsUtWY9X1gW=vAvoeQS8RHg@mail.gmail.com>
From: Steven M Jones <smj@crash.com>
Message-ID: <b7ea6cb8-ce79-7df7-c521-544358c1866e@crash.com>
Date: Wed, 27 Jan 2021 19:17:06 -0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:78.0) Gecko/20100101 Thunderbird/78.6.1
MIME-Version: 1.0
In-Reply-To: <CAL0qLwbN+HkGfvw79rPPvqL6jWWAsUtWY9X1gW=vAvoeQS8RHg@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------A536FB636D3C75D0D25CA65E"
Content-Language: en-US
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (segv.crash.com [72.52.75.15]); Thu, 28 Jan 2021 03:17:14 +0000 (UTC)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/QYmF2JTskPIurbPWRmBsIUJr6mE>
Subject: Re: [dmarc-ietf] Forensic report loops are a problem
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: Thu, 28 Jan 2021 03:17:20 -0000

On 1/27/21 12:47, Murray S. Kucherawy wrote:
> On Wed, Jan 27, 2021 at 12:37 PM John Levine <johnl@taugh.com
> <mailto:johnl@taugh.com>> wrote:
>
>     I still don't understand why failure reports about messages that
>     happen to be failure reports are in any way special.
>
>
> Loop detection in RFC 5321 is a normative MUST because of the obvious
> operational problems it creates.  Maybe I'm being thick, but right now
> I don't see how this is different, apart from the fact that each
> message is distinct; you're still causing a problem by turning this on
> without a care in the world about whether two verifiers start spamming
> each other.


There's coverage in 7489 Section 7.2 that a domain owner can
inadvertently DDoS themselves via failure reports. And that still
surprised many implementers, even though it seemed obvious to them in
retrospect.

This case is even less obvious, and we still have questions coming in
about it from new implementers.

I don't think it's a security consideration because it doesn't scale up
the way "ruf" can, so it deserves a brief mention here. But I would
rephrase Ale's last sentence:


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 for authentication, as failure to authenticate
   failure reports may result in mail loops.  These loops can be mitigated
   by sending reports from a domain or subdomain that doesn't request
   reports, or by performing rate limiting for report receiving mailboxes.


--S.