[dmarc-ietf] DMARC2 & SPF Dependency Removal

Tobias Herkula <tobias.herkula@1und1.de> Thu, 08 June 2023 13:00 UTC

Return-Path: <tobias.herkula@1und1.de>
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 BF365C14CF18 for <dmarc@ietfa.amsl.com>; Thu, 8 Jun 2023 06:00:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.097
X-Spam-Level:
X-Spam-Status: No, score=-7.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=1und1.de
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ssxBGBLmMFD for <dmarc@ietfa.amsl.com>; Thu, 8 Jun 2023 05:59:56 -0700 (PDT)
Received: from moint.1and1.com (moint.1and1.com [212.227.15.7]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F938C14CF1E for <dmarc@ietf.org>; Thu, 8 Jun 2023 05:58:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=1und1.de; s=corp1; h=MIME-Version:Message-ID:Date:Subject:To:From:cc:sender:reply-to; bh=tryMt0jWrBBdyzaPlnObQ12dNzLDj+H+xkanD86uwLA=; b=DmgpBmc3KK/0bTQYk1fKMA9Cp todTxtS9cYCGnHNi2tC8vuIdUA7CLo+aDbjVNGW35ixpLDRxMheZPmw6h4/16ZQbWsP+Xl8Dt4v1H 6QaDePNqcXLfYMQVeBCFV2buivzzGSih8wR1nr7HtH0XA5MBL1TG5MmQ8zkyDpdnTwJGVmhKBH32z jwqoKen4o+nKmAgmBuc4bC0OuqNLBfNfrzThcjk819/OYPpvP9Y5O6+WqClFFD9gOUoSFoMID5a4l 7xJvCe8x0xUBqnjOPLZ0dqPeuPs6RDURukJw8LJFd+JHm2CeoXHu0wwAyPs746UNP0JGdaQ5CLDGs okAci6UlQ==;
Received: from [10.98.29.9] (helo=BAPPEX024.united.domain) by mrint.1and1.com with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <tobias.herkula@1und1.de>) id 1q7FE4-0008Ki-GK for dmarc@ietf.org; Thu, 08 Jun 2023 14:58:52 +0200
From: Tobias Herkula <tobias.herkula@1und1.de>
To: "dmarc@ietf.org" <dmarc@ietf.org>
Thread-Topic: DMARC2 & SPF Dependency Removal
Thread-Index: AQHZmgj58ilP1Yl1OkWcMmRlCwBUjw==
Date: Thu, 08 Jun 2023 12:58:51 +0000
Message-ID: <30BB83B2-B454-41B8-992B-8E2569802D9C@1und1.de>
Accept-Language: en-US, de-DE
Content-Language: de-DE
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.98.28.55]
Content-Type: multipart/alternative; boundary="_000_30BB83B2B45441B8992B8E2569802D9C1und1de_"
MIME-Version: 1.0
X-Virus-Scanned: ClamAV@mvs-ha-bs
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/2CcO17K8QcOmTORHl3_isQBm_RE>
Subject: [dmarc-ietf] DMARC2 & SPF Dependency Removal
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.39
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, 08 Jun 2023 13:00:00 -0000

Hi All,

This message comes out of some discussions I had at the current MAAWG meeting in Dublin.

I hope this message finds you well. The intent of this is to propose and discuss an evolutionary step in the DMARC protocol, which I believe will result in increased efficiency, reduced DNS load, and a more accurate reflection of the current email landscape.

My team recently concluded an extensive study on the current use and performance of DMARC. We analyzed a staggering 3.2 billion emails, and the insights drawn are quite enlightening. Of these, 2.2 billion emails (approximately 69%) passed the DMARC check successfully. It's quite an achievement, reflective of our collective hard work in fostering a safer, more secure email environment.

However, upon further analysis, it's evident that a mere 1.6% (or thirty-six million) of these DMARC-passed emails relied exclusively on the Sender Policy Framework (SPF) for validation. This is a remarkably low volume compared to the overall DMARC-passed traffic, raising questions about SPF's relevancy and the load it imposes on the DNS systems.

Given the current use case scenarios and the desire to optimize our resources, I propose that we explore the possibility of removing the SPF dependency from DMARC. This step could result in a significant reduction in DNS load, increased efficiency, and an accurate alignment with our predominant use cases.

However, such a fundamental shift in the protocol's architecture warrants a clear signifier. I suggest we upgrade our DMARC version string from the current state to 'DMARC2.' This upgrade would not only denote the change of SPF removal, but also the switch from the Public Suffix List (PSL) to the Tree-Walk algorithm.

By moving towards DMARC2, we not only update our standard to better reflect our present requirements, but we also make a clear commitment to the ongoing evolution and improvement of the protocol.

Best regards,

Tobias Herkula
Mail Security & Transfer
1&1 (GMX, Web.de, Mail.com, IONOS)