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

Alessandro Vesely <vesely@tana.it> Wed, 27 January 2021 18:08 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 7E15F3A0D2E for <dmarc@ietfa.amsl.com>; Wed, 27 Jan 2021 10:08:51 -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 8y8Fpq1QtzAB for <dmarc@ietfa.amsl.com>; Wed, 27 Jan 2021 10:08:49 -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 B4AC33A0D38 for <dmarc@ietf.org>; Wed, 27 Jan 2021 10:08:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1611770927; bh=PNCIC0cnXHgibKJzUMWTQYfJ5a2eqewG6TZcHqve8X4=; l=1768; h=To:References:From:Date:In-Reply-To; b=ALEd13FJvKTmMZYu3/V23hZbMYMnaDRoS5fgjTmgmBPaF8nqPd6+MM1SQ23L/eNeD G9OBOR45kH1IJY1/tQSaqofJkGKObvacHkC5v8vSbUHcYZWbZ+V4CDXf+y91EQWW8t ooTw6DCpYLETU8d6/tVcQ4JX6doApPUFRFidx5VNyfkluxJM7hh4wy8lvxOGO
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 00000000005DC07E.000000006011AC2F.00005B99; Wed, 27 Jan 2021 19:08:47 +0100
To: John R Levine <johnl@taugh.com>, IETF DMARC WG <dmarc@ietf.org>
References: <CAL0qLwaZx97cztehz_o=cCVZRbEP_yFVS9hTqWDKg7cMgjNvFg@mail.gmail.com> <20210116034026.5C93F6AC0428@ary.qy> <CAL0qLwatEsNrfF5GeWoVhrk_By8K84mYdBNOUFiN7cBaAch8JQ@mail.gmail.com> <29f5c140-6b07-e3be-f188-8b2104690385@tana.it> <52ea482c-86f8-f879-eefb-ff14e8819b56@taugh.com>
From: Alessandro Vesely <vesely@tana.it>
Message-ID: <d54e8930-5266-7622-183d-023f9e35e385@tana.it>
Date: Wed, 27 Jan 2021 19:08:46 +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: <52ea482c-86f8-f879-eefb-ff14e8819b56@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/jfUcwVKXUdUpF0Cg5SHoWSZ3m4o>
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: Wed, 27 Jan 2021 18:08:52 -0000

On Wed 27/Jan/2021 17:17:38 +0100 John R Levine wrote:
> 
>> While [loops are] a minor problem for aggregate reports, it can be a real problem 
>> for naive failure reports generators.  Juri reported he had to target a 
>> specific address, attributing the loop to a remote misconfiguration. However, 
>> if it is possible to screw up authentications, the probability to meet a loop 
>> is just its square, times the number of generators.
> 
> If the authentication is screwed up, sending a failure report is exactly the 
> right thing to do.  That's what they're for.


Even if the screwed up message was a failure report itself?


> I think we should close this.  DMARC is working the way it is supposed to, and 
> people don't want to get reports about their reports, there are obvious ways to 
> prevent them, like not sending unaligned reports,


Oh, there is a sentence in the current spec:

    Email streams carrying DMARC feedback data MUST conform to the DMARC
    mechanism, thereby resulting in an aligned "pass" (see Section 3.1).

As it stands, it's valid for both aggregate and failure reports.  However, it 
happened to land on the aggregate-reporting I-D only.


> or sending reports from a domain that doesn't get reports back.

That was one of the hints I proposed.  Your wording is better.  Added this:

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.  Besides rate limiting,
    such loops can also be avoided by sending reports from a domain that
    doesn't get reports back.

Is that all right?


Best
Ale
--