Re: [dmarc-ietf] Discussion: Removal of validation for external destinations (Ticket #76)

Alessandro Vesely <vesely@tana.it> Sun, 06 December 2020 12:06 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 930093A0CD4 for <dmarc@ietfa.amsl.com>; Sun, 6 Dec 2020 04:06:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.12
X-Spam-Level:
X-Spam-Status: No, score=-2.12 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, SPOOF_COM2OTH=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 nSa8OgDvcG-v for <dmarc@ietfa.amsl.com>; Sun, 6 Dec 2020 04:06:16 -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 7C7843A0CD5 for <dmarc@ietf.org>; Sun, 6 Dec 2020 04:06:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1607256373; bh=f4qTKLaRukB0C3cDcaQlqxTZEtuuWsGZNcuIKKwJ2rA=; l=1554; h=To:References:From:Date:In-Reply-To; b=BxYpxCxrj2SWglq4TNY7xYqgJ7M9udOcbggBzZcJ4wQ+z+g7Xd/YkWZRLbnXEzmwk S4U0QLuVI8UKCZP1PovPrXnet8IVBFFBgdZpviB8+Scb3+b/ZHgorZTBHct0TGmWcd 1lRD0jlTXJSmPooS3WuaoakgAEewmTGRdKq8Z19CyDUVld0q4f1LOvX7y2HKA
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 00000000005DC056.000000005FCCC935.00003EAB; Sun, 06 Dec 2020 13:06:13 +0100
To: dmarc@ietf.org
References: <MN2PR11MB4351D62302C7357DE653F8B4F7F00@MN2PR11MB4351.namprd11.prod.outlook.com>
From: Alessandro Vesely <vesely@tana.it>
Message-ID: <fc1d9d7c-4e14-78af-0416-b6cfb0873468@tana.it>
Date: Sun, 6 Dec 2020 13:06:12 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0
MIME-Version: 1.0
In-Reply-To: <MN2PR11MB4351D62302C7357DE653F8B4F7F00@MN2PR11MB4351.namprd11.prod.outlook.com>
Content-Type: text/plain; charset=us-ascii
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/FJKR29C_ptU8yUlc9pbHUrUhkeQ>
Subject: Re: [dmarc-ietf] Discussion: Removal of validation for external destinations (Ticket #76)
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: Sun, 06 Dec 2020 12:06:19 -0000

On Sat 05/Dec/2020 14:51:52 +0100 Brotman, Alex wrote:
> 
> There's currently a ticket that suggests that the requirement for external validation be removed.  Today, if example.com has an RUA that points at example.net, the latter must create a record as such:
> 
> example.com._report._dmarc.example.net TXT "v=DMARC1"


Actually, the record can also be:

example.com._report._dmarc.example.net TXT "v=DMARC1; rua=updated-address@example.net"

or even, considering a parallel thread:

example.com._report._dmarc.example.net TXT "v=DMARC1; rua=report@example.net, /https://www.example.net/report/"


That way, external services have the ability to control or suspend  their service.  I think this is an essential requirement.  Let's keep it.


> The original thought was that a bad actor could overwhelm a target with unrequested reports.  It seems in reality, most report generators only send once per day.


Once-per-day has to be amended.  See ticket #71.


> Additionally, there appear to be some generators who ignore the absence of these records.


Aggregate reports are often tagged as spam anyway, but when sent in violation of the spec such tagging is certainly deserved.


> https://tools.ietf.org/html/rfc7489#section-7.1


Why don't you refer to either of the drafts we're editing:
https://tools.ietf.org/html/draft-ietf-dmarc-aggregate-reporting-00#section-2.1
https://tools.ietf.org/html/draft-ietf-dmarc-failure-reporting-00#section-3.2

BTW, this duplication is worth yet another ticket.


Best
Ale
--