Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal

Hector Santos <hsantos@isdg.net> Thu, 08 June 2023 17:47 UTC

Return-Path: <hsantos@isdg.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 B2B7BC14CE39 for <dmarc@ietfa.amsl.com>; Thu, 8 Jun 2023 10:47:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 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_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=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isdg.net header.b="dr7Zqxuh"; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b="eW00ypxn"
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 nOoliYTuRkoi for <dmarc@ietfa.amsl.com>; Thu, 8 Jun 2023 10:46:56 -0700 (PDT)
Received: from mail.winserver.com (mail.winserver.com [3.137.120.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AA8FC14CEF9 for <dmarc@ietf.org>; Thu, 8 Jun 2023 10:46:56 -0700 (PDT)
DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha256; c=simple/relaxed; l=12329; t=1686246046; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:From:Message-Id:Subject: Date:To:Organization:List-ID; bh=ZzgzOuEX2pisXj37vlRgwrOdh/A97hz /oFJmVlz5HgU=; b=dr7ZqxuhKnQ3XEv/mJVVy/anYckTDGnqw2ou4AkVzxikb5k ML/1yBEXvjLdKs/u/9pePtZgsZ6NZwcmJ9gdx4Rv017L5YyNKVaNzZD89jKR+Did xwTCsHRUrmUoDZ8DdA0/0kcWuaf5rkmA1sEwgOowjuLig80susr0JA7kedUM=
Received: by winserver.com (Wildcat! SMTP Router v8.0.454.13) for dmarc@ietf.org; Thu, 08 Jun 2023 13:40:45 -0400
Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=none author.d=isdg.net signer.d=beta.winserver.com; dmarc=pass policy=reject author.d=isdg.net signer.d=beta.winserver.com (atps signer);
Received: from beta.winserver.com ([3.132.92.116]) by winserver.com (Wildcat! SMTP v8.0.454.13) with ESMTP id 2343787505.1.9048; Thu, 08 Jun 2023 13:40:45 -0400
DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=12329; t=1686242259; h=Received:Received: From:Message-Id:Subject:Date:To:Organization:List-ID; bh=ZzgzOuE X2pisXj37vlRgwrOdh/A97hz/oFJmVlz5HgU=; b=eW00ypxn+zXFZnxv+atMtID TQblr6ZO2OBK43aoa23FU1RinjCy0X9mOkEI3bpZJvPahuW0KGN7yEHKgDtVGJwq /hJ9PX6onG5c2O5rLLgYPft4HoEB9ooh24SlTcZLI6i9qRlGUWmzFxWHvFtowNl2 eDdE7rtJ5vUBPgIK15mQ=
Received: by beta.winserver.com (Wildcat! SMTP Router v8.0.454.12) for dmarc@ietf.org; Thu, 08 Jun 2023 12:37:39 -0400
Received: from smtpclient.apple ([99.122.210.89]) by beta.winserver.com (Wildcat! SMTP v8.0.454.12) with ESMTP id 2786053786.1.5256; Thu, 08 Jun 2023 12:37:38 -0400
From: Hector Santos <hsantos@isdg.net>
Message-Id: <BC817A21-07EB-4451-90F2-66FBE3BA15A3@isdg.net>
Content-Type: multipart/alternative; boundary="Apple-Mail=_0CE0B6C8-2F4B-402B-B302-DA7BDCA14BFC"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.400.51.1.1\))
Date: Thu, 08 Jun 2023 12:37:27 -0400
In-Reply-To: <CAL0qLwbx6Y=kmB5pQZx8gNqD=rLBYz1vLOX6ngL=wUHHUm0Hjw@mail.gmail.com>
Cc: Tobias Herkula <tobias.herkula=401und1.de@dmarc.ietf.org>, "dmarc@ietf.org" <dmarc@ietf.org>
To: "Murray S. Kucherawy" <superuser@gmail.com>
References: <30BB83B2-B454-41B8-992B-8E2569802D9C@1und1.de> <CAL0qLwbx6Y=kmB5pQZx8gNqD=rLBYz1vLOX6ngL=wUHHUm0Hjw@mail.gmail.com>
X-Mailer: Apple Mail (2.3731.400.51.1.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/ddC_8ciR7nGqhyKd3Nn9-v_3TGA>
Subject: Re: [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 17:47:00 -0000


> On Jun 8, 2023, at 10:20 AM, Murray S. Kucherawy <superuser@gmail.com> wrote:
> 
> On Thu, Jun 8, 2023 at 6:00 AM Tobias Herkula <tobias.herkula=401und1.de@dmarc.ietf.org <mailto:401und1.de@dmarc.ietf.org>> wrote:
>> 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.
>> 
>> [...]
>> 
> 
> Does anyone have consonant (or dissonant) data? 
> 



Thank you for inviting feedback on Mr. Herkula's interesting DMARC2 proposal, focusing on detaching SPF from DMARC's evaluation process. I would like to share my thoughts on this matter.

While the principle behind the proposed DMARC2 is valuable, I remain sceptical about the effectiveness of separating SPF from DMARC to alleviate DNS load. For various reasons, notably the layer issue – SPF being an SMTP protocol rather than a payload protocol – SPF is unlikely to be fully discarded.

It's worth recalling that SPF's contribution has served the email community well, despite certain node transition issues such as relays and forwards. The optional integration of SPF within DMARC1 from the onset might have simplified the process, mitigating the challenges associated with the merged results and reducing the occurrence of false positives, which in many cases has begun to give domains a second thought on using p=reject|quarantine policies. 

A potential DMARC2 proposal should, in my opinion, maintain backward compatibility, making SPF an optional requirement.  The real gap with DMARC1 has been the lack of diversity in policies, and effectively, the DMARC2 proposal could add a new "policy" that doesn't require SPF evaluation.

For context, we've amassed nearly two decades worth of data on SPF, DKIM, ADSP, and DMARC, providing considerable insight into the longevity and effectiveness of these measures.

It's crucial to establish that SPF was deliberately designed to, and in many cases will, use a HARDFAIL result to preempt payload transfer or its acceptance (at DATA). This is precisely why the SUBMITTER add-on ESMTP protocol was introduced as part of SenderID – the payload version of SPF – to relay the Purported Responsible Address (PRA) at the SMTP MAIL FROM command.

By reviving the SUBMITTER protocol for DMARC purposes, servers/receivers can check the DMARC policy at SMTP, offering valuable foresight into the email domain's expectations prior to payload delivery. This approach allows for a more optimized process, ensuring that SPF is evaluated at MAIL FROM or RCPT TO, once the recipient address's acceptability is established per RFC 5321, Section 3.3 Mail Transactions' recommendations.

It's important to note that SPF-compliant servers – as evidenced recently by gmail.com – can reject SPF failures at SMTP independent of DMARC. For domains using SPF hard failures (-ALL), DMARC is not mandatory and in many cases, a hard SPF policy vs hard  DMARC policies are mutual exclusive.  Odds are good, if SPF was disabled, DMARC2 could yield the same way. I suggest that the proposed DMARC2 revisit the coupling of SOFTFAIL SPF results with DMARC2 policy analysis.  

While DMARC has introduced complexities and some uncertainty, my recent analysis reveals that domains without DMARC, but implementing hard SPF policies, experienced minimal issues, except for gmail.com domain members. The problem appears to be more prominent with ESPs, particularly those with a lenient DMARC p=nonen since ESPs with strong policies are restricted from subscriptions and submissions.

In conclusion, the evolution to a DMARC2 should focus on addressing these concerns, potentially including a "rewrite=1" option to mailing lists with appropriate permissions. This could potentially make it more palatable to modify the author's address, while respecting the hard-won email security principles.

Thanks

---
Hector Santos
Santronics Software,Inc.