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

Hector Santos <hsantos@isdg.net> Thu, 08 June 2023 17:40 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 431F6C14CE25 for <dmarc@ietfa.amsl.com>; Thu, 8 Jun 2023 10:40:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.096
X-Spam-Level:
X-Spam-Status: No, score=-7.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_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 (1024-bit key) header.d=isdg.net header.b="f4zGDRAq"; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b="JVbrtPVO"
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 cSuoIMeOhzTb for <dmarc@ietfa.amsl.com>; Thu, 8 Jun 2023 10:39:55 -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 F3E37C14CEF9 for <dmarc@ietf.org>; Thu, 8 Jun 2023 10:39:54 -0700 (PDT)
DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha256; c=simple/relaxed; l=14114; t=1686245990; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:From:Message-Id:Subject: Date:To:Organization:List-ID; bh=CkQwISY9FovEYfEPrzHOuCF4Xm6fwBO BZKZU/0/yZtA=; b=f4zGDRAqWZIbQ7BjTj5/W5ymqknG/k5pPNqt6ZYKgUyxv0g LQTht2naxWwJlfOW6R8trnIvnk1U432hguPXP/ojgNNzjXLpEnKkxy3MAJU1cWIu HMQorHwITcpJcyiUJgtnFKW/amvRU3yQPGPbYPyd3t1Vn2ye5nHlBFkPDn8A=
Received: by winserver.com (Wildcat! SMTP Router v8.0.454.13) for dmarc@ietf.org; Thu, 08 Jun 2023 13:39:50 -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 2343731770.1.5948; Thu, 08 Jun 2023 13:39:49 -0400
DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=14114; t=1686243455; h=Received:Received: From:Message-Id:Subject:Date:To:Organization:List-ID; bh=CkQwISY 9FovEYfEPrzHOuCF4Xm6fwBOBZKZU/0/yZtA=; b=JVbrtPVOzIdjIFHevpllj7O ZPey3z4UxJsRKgIUgehQsekeQ55CKwH017TTalv3AieNnJKukH5K5JFZAXx+c7M4 KpTjG6/pSUivEP7+KhWhvnM7hvGkl2leVs+ei6XhmVAcNe6GS8i54l06G+pUQYzp GzIsfbD7xh1f83CScNGU=
Received: by beta.winserver.com (Wildcat! SMTP Router v8.0.454.12) for dmarc@ietf.org; Thu, 08 Jun 2023 12:57:35 -0400
Received: from smtpclient.apple ([99.122.210.89]) by beta.winserver.com (Wildcat! SMTP v8.0.454.12) with ESMTP id 2787249255.1.8348; Thu, 08 Jun 2023 12:57:34 -0400
From: Hector Santos <hsantos@isdg.net>
Message-Id: <11407D0F-C8A4-4C53-A182-CD18FCF4E74A@isdg.net>
Content-Type: multipart/alternative; boundary="Apple-Mail=_935BA0D7-047D-441B-9E2F-6BFB16BCCCA7"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.400.51.1.1\))
Date: Thu, 08 Jun 2023 12:57:23 -0400
In-Reply-To: <CALaySJJ9Lp3L1mERabigr96Ue3QO5Jx6=qedTs=Q-FoDdODwUg@mail.gmail.com>
Cc: Seth Blank <seth@sethblank.com>, Seth Blank <seth=40valimail.com@dmarc.ietf.org>, Tobias Herkula <tobias.herkula=401und1.de@dmarc.ietf.org>, "dmarc@ietf.org" <dmarc@ietf.org>
To: Barry Leiba <barryleiba@computer.org>
References: <30BB83B2-B454-41B8-992B-8E2569802D9C@1und1.de> <CAL0qLwbx6Y=kmB5pQZx8gNqD=rLBYz1vLOX6ngL=wUHHUm0Hjw@mail.gmail.com> <CAOZAAfMtsjcp+aCrwQ2QRc+SHsw3rhwMuTBugRYe44NeiMeKyg@mail.gmail.com> <CALaySJKrXJJXz3pgp85BPswoirhPJtD=uuefVfc9sX1fGkj-iA@mail.gmail.com> <CAD2i3WMbVZ0-yQeqoy7P9njyBRU2jdbP2jGtzUnzEE0dfsLR2g@mail.gmail.com> <CALaySJJ9Lp3L1mERabigr96Ue3QO5Jx6=qedTs=Q-FoDdODwUg@mail.gmail.com>
X-Mailer: Apple Mail (2.3731.400.51.1.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/uY4mtL_H-E8Ee9uCKEDBBlasT-Y>
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:40:00 -0000

My #1 concern is how the bigger ESP is contributing to the delivery problems, causing chaos for business users and customer relationship problems with mail hosting provider  I am seeing uncertainty and inconsistency among different receivers with ESP gmail.com seems to be the most aggressive and I am seeing the bigger ESPs using different methods, including proprietary methods.

As a sideline note, I will venture email overhead has skyrocketed to a new level of hard to follow headers for tech support. I don’t think we can continue down this path in the name of trying to get DMARC as apart of everyone’s domain when in fact, it is unfortunately becoming more apparent, a domain may be is better off with no DMARC record, not even p=none may help. Using SPF is good enough it seems.

—
HLS

> On Jun 8, 2023, at 11:02 AM, Barry Leiba <barryleiba@computer.org> wrote:
> 
> I disagree with the premise (the last sentence of your first paragraph).  Broken or ineffective authentication is worse than none, because it causes deliverability problems.  I’d rather have no authentication and rely on other means of filtering.
> 
> Barry
> 
> On Thu, Jun 8, 2023 at 3:54 PM Seth Blank <seth@sethblank.com <mailto:seth@sethblank.com>> wrote:
>> Participating, while running around so apologies for terseness:
>> 
>> Sophisticated senders do DKIM. The long tail, we're lucky if they do SPF. Some authentication is better than none.
>> 
>> The problem isn't people evaluating SPF vs DKIM and choosing the easier option. It's people who have a business, who bolt on email, and then struggle to authenticate through any means. Again, we're lucky when we get SPF from them, and I'll still take that over no auth all day every day.
>> 
>> Don't disagree at all with the myriad problems with SPF, and that the goal should be to eliminate it. I just don't believe we're anywhere close to that being a reality yet.
>> 
>> The data that led to DMARC showed that SPF and DKIM were both necessary to determine legitimacy broadly. What would we need to understand now to see if only DKIM is necessary?
>> 
>> On Thu, Jun 8, 2023 at 3:44 PM Barry Leiba <barryleiba@computer.org <mailto:barryleiba@computer.org>> wrote:
>>> See, I don't look at it as "harmed".  Rather, I think they're using "we use SPF" as a *reason* not to use DKIM, and I think that *causes* harm.
>>> 
>>> SPF is, as I see it, worse than useless, as it adds no value to domain that use DKIM -- any time DKIM fails SPF will also fail -- and actually impedes the adoption of DKIM.  Reliance on SPF causes DMARC failures that result in deliverability problems for legitimate mail.  I wholeheartedly support removal of SPF as an authentication mechanism that DMARC accepts.
>>> 
>>> Barry, as participant
>>> 
>>> On Thu, Jun 8, 2023 at 3:30 PM Seth Blank <seth=40valimail.com@dmarc.ietf.org <mailto:40valimail.com@dmarc.ietf.org>> wrote:
>>>> Participating, I have data that I believe points to a long tail of businesses who predominantly only authenticate on behalf of others using SPF, and would be harmed by such a change. It will take me a little while to confirm and share.
>>>> 
>>>> I also know a predominant ccTLD with millions of registrations, that has SPF on roughly 80% of them, but DMARC on barely 5%. I don't have data on DKIM for those, but I assume it's closer to the DMARC penetration than the SPF one. I'll see if I can get this data to share more publically, and also get the DKIM answer.
>>>> 
>>>> Of course the goal is aligned dkim with a stated policy, but I don't think the data supports us being anywhere close to that realistically. 
>>>> 
>>>> As Chair, this is a valuable conversation to have with real data on problems and opportunities at scale, and am excited to see Tobias share and see what others have to say.
>>>> 
>>>> Seth
>>>> 
>>>> On Thu, Jun 8, 2023 at 3:21 PM Murray S. Kucherawy <superuser@gmail.com <mailto: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? 
>>>>> 
>>>>> -MSK, participating
>>>>> ______________