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

Marc Bradshaw <marc@marcbradshaw.net> Mon, 07 December 2020 22:25 UTC

Return-Path: <marc@marcbradshaw.net>
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 3474F3A0BA4 for <dmarc@ietfa.amsl.com>; Mon, 7 Dec 2020 14:25:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.118
X-Spam-Level:
X-Spam-Status: No, score=-2.118 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, RCVD_IN_MSPIKE_H4=-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 (2048-bit key) header.d=marcbradshaw.net header.b=XuoiYvmS; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=MV6R3ZlA
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 bO2a8JYR5IqE for <dmarc@ietfa.amsl.com>; Mon, 7 Dec 2020 14:25:49 -0800 (PST)
Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 342343A0B85 for <dmarc@ietf.org>; Mon, 7 Dec 2020 14:25:49 -0800 (PST)
Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id BBD0C153D for <dmarc@ietf.org>; Mon, 7 Dec 2020 17:25:47 -0500 (EST)
Received: from imap10 ([10.202.2.60]) by compute3.internal (MEProxy); Mon, 07 Dec 2020 17:25:47 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= marcbradshaw.net; h=mime-version:message-id:in-reply-to :references:date:from:to:subject:content-type; s=fm2; bh=+SfAfan q/dPh/WQx5bze8a9H8PCw33Xko33BJUigSU4=; b=XuoiYvmS0pTmR7Mx8eMKLtn G4RCVMeOqmOie3UoKGF8of7+WEMHBoPV8hMFQzIIsEoxFfjMYx07Ti84xWobSfRH GV+bCe/J/FKdheEFVrgTxuIAOzJPF2gVo2KzY0825kdnMIH+gXgzEY3c/CC9q/tX PMU4PM9IKI0+cDhlK6lmf9yOvpB0W+eD7ySnsPj4FSxam4QNEjXtWMKeaCTXaxUj Qi/VebjxLQU3jnQSqLU7XYjkGqHuL7LqZIsH5u58sE4g8toYJEhLUMQdPxnLh6bo 1swm9fMClwy79PJxf8qirZmz2cEwSzdGi/sTIZvXRDManC9UiPcrUkP2rRA6jUA= =
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=+SfAfa nq/dPh/WQx5bze8a9H8PCw33Xko33BJUigSU4=; b=MV6R3ZlAuuclrqKMWbJzPI FWvALSscSYDIhTbgcSaeABxYeAqAQKy/EoOb4gNCpGFP8tFfmHZhTsG7DOCzgPM3 vuWj/l3/DazMIKyHKK3wyq4ohvutA7In4y1DK0YuHbrPaeY0LOSMq+0ec4lBykQo rUSVqGHYQv8YD3RE2Y8FqaYrRgOzMOSE47RdUsRtTn4mTnBcadK94cTVZGnOqSSG OjTKIcDD5dOBAL5Xg4T9o9uO5YYcoikAIEuu2Gybg+K/oUjs5u3Q//mCaCBZvg8C 6RN5frKVU5eE228RyHM3FIK/BvSHBPVRDORKkzl+sKfF5hyQt1GIgHNbb+G7XMOw ==
X-ME-Sender: <xms:6qvOX2AF7giFMY-RWYhN1YExjxev0Wpqy_H9WzPqdSOroudLQ3Jghg> <xme:6qvOXwimoiL6IV67W0ylNUbSOhojpfNcrjClakWA4vpSd54KwEjTc3efZbP88OZKF 6caT45ujOlxLiV9rA>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrudejgedgudeitdcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enogfuuhhsphgvtghtkfhmghffohhmrghinhculdeftddmnecujfgurhepofgfggfkjghf fffhvffutgesrgdtreerreerjeenucfhrhhomhepfdforghrtgcuuehrrggushhhrgiffd cuoehmrghrtgesmhgrrhgtsghrrggushhhrgifrdhnvghtqeenucggtffrrghtthgvrhhn pefhtdevheetgfevgedvudekjeejieeuvdeftddvueevvdegheeuudevtddtjedvvdenuc ffohhmrghinhepvgigrghmphhlvgdrnhgvthdpihgvthhfrdhorhhgpdhmrghrtggsrhgr ughshhgrfidrnhgvthdpthifihhtthgvrhdrtghomhenucevlhhushhtvghrufhiiigvpe dtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmrghrtgesmhgrrhgtsghrrggushhhrgif rdhnvght
X-ME-Proxy: <xmx:6qvOX5k5LNdgdwWEBLtzYgr2jayaj88cmh5tsXahIpi9_z8joTIVgg> <xmx:6qvOX0xog2Wt6jZ2UJ7Cach59ESEVJZBG0wQVGcUnU5ycyZ40tbZ2Q> <xmx:6qvOX7R0-5ImoCaJAe_iYPcMpyeXMA3hZv82gUUlW6IcthBbteP9RA> <xmx:66vOXye8Ne9bGNzf7iHuH6cGIayvVtYZme1ArozKVn4soP9iUrJDCQ>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id A311B20126; Mon, 7 Dec 2020 17:25:46 -0500 (EST)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.3.0-622-g4a97c0b-fm-20201115.001-g4a97c0b3
Mime-Version: 1.0
Message-Id: <0359b009-5b18-46f8-85a5-959ad337dd49@beta.fastmail.com>
In-Reply-To: <fc1d9d7c-4e14-78af-0416-b6cfb0873468@tana.it>
References: <MN2PR11MB4351D62302C7357DE653F8B4F7F00@MN2PR11MB4351.namprd11.prod.outlook.com> <fc1d9d7c-4e14-78af-0416-b6cfb0873468@tana.it>
Date: Tue, 08 Dec 2020 09:25:10 +1100
From: "Marc Bradshaw" <marc@marcbradshaw.net>
To: "DMARC IETF" <dmarc@ietf.org>
Content-Type: multipart/alternative; boundary=8a1f2393ae514dfba4b0d41fa2cc6031
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/BWEgpzkbJbbsc9UJTQmiV_PpXU0>
Subject: Re: [dmarc-ietf] =?utf-8?q?Discussion=3A_Removal_of_validation_for_e?= =?utf-8?q?xternal_destinations_=28Ticket_=2376=29?=
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, 07 Dec 2020 22:25:51 -0000

Removing this opens up the potential for abuse, I don't see the value in removing it.

On Sun, 6 Dec 2020, at 11:06 PM, Alessandro Vesely wrote:
> 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
> -- 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
> 

--

  Marc Bradshaw
  marcbradshaw.net | @marcbradshaw <https://twitter.com/marcbradshaw>