From nobody Thu Jun 8 08:02:32 2023 Return-Path: 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 8CC6CC151085 for ; Thu, 8 Jun 2023 08:02:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.548 X-Spam-Level: X-Spam-Status: No, score=-1.548 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.096, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no autolearn_force=no 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 4IvcPdjNuRAm for ; Thu, 8 Jun 2023 08:02:29 -0700 (PDT) Received: from mail-ed1-f51.google.com (mail-ed1-f51.google.com [209.85.208.51]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 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 89D7AC15107D for ; Thu, 8 Jun 2023 08:02:29 -0700 (PDT) Received: by mail-ed1-f51.google.com with SMTP id 4fb4d7f45d1cf-510d6b939bfso1306884a12.0 for ; Thu, 08 Jun 2023 08:02:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1686236548; x=1688828548; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=7wCmNuQkIhlxOAJLlppfnf+bxKcjCGc5id0/qTesW+g=; b=cj7iICR1zhN5V8GFIKfUuqVd+esVSL26iIP5bsEGSD+A5gcFglsFCLzcyoKZktdK19 tzzvBBGcWa9VlY4nJCrlAAEazl7cLIuQXAgNmTsQCJGw1+cstXzCqx4+4e8O6Db6ShnJ 8pn634iMHsALU5p44FzYJ369oPY7TPMFdm6XJFcQlfDiulb3SvP4/sdgQ/LuXX8LjENn piBsBMEPD8Sf1ogOuTIazUqUoq+SPygYJdux3Iu9fC0EMVSlodRv6PrAJ1Xm1Rza0AcD rIWQvv2IyJ2aaNEgQ1hkEx4EJdzboJ9+9j+436uBFaLVo1UPw+T89ubgkfwOYyrVt5/w uQ5A== X-Gm-Message-State: AC+VfDyweu9Y9BE78R6Q7BD2BpE+bsuZGmINBL+HEcbfMMzcQJ6Z/qjd GJtRDzXK+bYOA2DqPYxaW+y6KLc3cy03o8CZmXM= X-Google-Smtp-Source: ACHHUZ7BL3zkIr+fNU8ziVn7CL3i/AO7vfvBP8BAAnjXcCn4Drqe3uV8nOEjbVwTJIRwsNrxUN28utEA665lrDGBE/s= X-Received: by 2002:a17:906:4792:b0:973:ad8f:ef9b with SMTP id cw18-20020a170906479200b00973ad8fef9bmr44062ejc.5.1686236547587; Thu, 08 Jun 2023 08:02:27 -0700 (PDT) MIME-Version: 1.0 References: <30BB83B2-B454-41B8-992B-8E2569802D9C@1und1.de> In-Reply-To: From: Barry Leiba Date: Thu, 8 Jun 2023 16:02:16 +0100 Message-ID: To: Seth Blank Cc: Seth Blank , Tobias Herkula , "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="0000000000006d222805fd9f8ae5" Archived-At: 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2023 15:02:30 -0000 --0000000000006d222805fd9f8ae5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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=E2=80=99d rather have no authentication and rel= y on other means of filtering. Barry On Thu, Jun 8, 2023 at 3:54 PM Seth Blank 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 ge= t > 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 goa= l > 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 t= o > 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=E2=80=AFPM Barry Leiba > 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 tha= t >> 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=E2=80=AFPM Seth Blank > 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 usin= g >>> SPF, and would be harmed by such a change. It will take me a little whi= le >>> to confirm and share. >>> >>> I also know a predominant ccTLD with millions of registrations, that ha= s >>> SPF on roughly 80% of them, but DMARC on barely 5%. I don't have data o= n >>> 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=E2=80=AFPM Murray S. Kucherawy >>> wrote: >>> >>>> On Thu, Jun 8, 2023 at 6:00=E2=80=AFAM Tobias Herkula >>> 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, an= d the >>>>> insights drawn are quite enlightening. Of these, 2.2 billion emails >>>>> (approximately 69%) passed the DMARC check successfully. It's quite a= n >>>>> achievement, reflective of our collective hard work in fostering a sa= fer, >>>>> 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 o= n the >>>>> Sender Policy Framework (SPF) for validation. This is a remarkably lo= w >>>>> volume compared to the overall DMARC-passed traffic, raising question= s >>>>> 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 reduct= ion in >>>>> DNS load, increased efficiency, and an accurate alignment with our >>>>> predominant use cases. >>>>> >>>>> [...] >>>>> >>>> >>>> Does anyone have consonant (or dissonant) data? >>>> >>>> -MSK, participating >>>> _______________________________________________ >>>> dmarc mailing list >>>> dmarc@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dmarc >>>> >>> >>> >>> -- >>> >>> *Seth Blank * | Chief Technology Officer >>> *e:* seth@valimail.com >>> *p:* 415.273.8818 >>> >>> This email and all data transmitted with it contains confidential and/o= r >>> proprietary information intended solely for the use of individual(s) >>> authorized to receive it. If you are not an intended and authorized >>> recipient you are hereby notified of any use, disclosure, copying or >>> distribution of the information included in this transmission is prohib= ited >>> and may be unlawful. Please immediately notify the sender by replying t= o >>> this email and then delete it from your system. >>> _______________________________________________ >>> dmarc mailing list >>> dmarc@ietf.org >>> https://www.ietf.org/mailman/listinfo/dmarc >>> >> _______________________________________________ >> dmarc mailing list >> dmarc@ietf.org >> https://www.ietf.org/mailman/listinfo/dmarc >> > --0000000000006d222805fd9f8ae5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I disagree with the premise (the last sentence of your fi= rst paragraph).=C2=A0 Broken or ineffective authentication is worse than no= ne, because it causes deliverability problems.=C2=A0 I=E2=80=99d rather hav= e no authentication and rely on other means of filtering.

Barry

On Thu, Jun 8, 2023 at 3:54 PM = Seth Blank <seth@sethblank.com= > wrote:
P= articipating, while running around so apologies for terseness:
Sophisticated senders do DKIM. The long tail, we're lucky if th= ey do SPF. Some authentication is better than none.

The = problem isn't people evaluating SPF vs DKIM and choosing the easier opt= ion. It's people who have a business, who bolt on email, and then strug= gle to authenticate through any means. Again, we're lucky when we get S= PF from them, and I'll still take that over no auth all day every day.<= /div>

Don't disagree at all with the myriad problems= with SPF, and that the goal should be to eliminate it. I just don't be= lieve we're anywhere close to that being a reality yet.

<= /div>
The data that led to DMARC showed that SPF and DKIM were both nec= essary to determine legitimacy broadly. What would we need to understand no= w to see if only DKIM is necessary?

On Thu, Jun 8, 2023 at 3:44=E2=80= =AFPM Barry Leiba <barryleiba@computer.org> wrote:
See, I don't look at = it as "harmed".=C2=A0 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.=C2=A0 Reliance on SPF causes DM= ARC failures that result in deliverability problems for legitimate mail.=C2= =A0 I wholeheartedly support removal of SPF as an authentication mechanism = that DMARC accepts.

Barry, as participant

On = Thu, Jun 8, 2023 at 3:30=E2=80=AFPM Seth Blank <seth=3D40valimail.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 ot= hers using SPF, and would be harmed by such a change. It will take me a lit= tle while to confirm and share.

I also know a predominan= t ccTLD with millions of registrations, that has SPF on roughly=C2=A080% 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 DK= IM 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.=C2=A0

As Chair, this= is a valuable conversation to have with real data on problems and opportun= ities 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=E2= =80=AFPM Murray S. Kucherawy <superuser@gmail.com> wrote:
On Thu,= Jun 8, 2023 at 6:00=E2=80=AFAM Tobias Herkula <tobias.herkula=3D401und1.de@dmarc.ie= tf.org> wrote:
My team recently concluded an extensive study on = the current use and performance of DMARC. We analyzed a staggering 3.2 bill= ion emails, and the insights drawn are quite enlightening. Of these, 2.2 bi= llion emails (approximately 69%) passed the DMARC check successfully. It's quite an achievement, r= eflective of our collective hard work in fostering a safer, more secure ema= il environment.

=C2=A0

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

=C2=A0

Given the current use case scen= arios and the desire to optimize our resources, I propose that we explore t= he possibility of removing the SPF dependency from DMARC. This step could r= esult in a significant reduction in DNS load, increased efficiency, and an accurate alignment with our predomi= nant use cases.

[...]


Does anyone have consonant = (or dissonant) data?=C2=A0

-MSK, participating
=
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc


--

Seth Blank <= /b> | Chief Technology Officer
e:<= /b> seth@valimail.com
p: 415.273.8818

This email = and all data transmitted with it contains confidential and/or proprietary i= nformation intended solely for the use of individual(s) authorized to recei= ve it. If you are not an intended and authorized recipient you are hereby n= otified of any use, disclosure, copying or distribution of the information = included in this transmission is prohibited and may be unlawful. Please imm= ediately notify the sender by replying to this email and then delete it fro= m your system.

_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
--0000000000006d222805fd9f8ae5--