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

Seth Blank <seth@sethblank.com> Thu, 08 June 2023 14:54 UTC

Return-Path: <seth@sethblank.com>
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 754A6C15108B for <dmarc@ietfa.amsl.com>; Thu, 8 Jun 2023 07:54:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.896
X-Spam-Level:
X-Spam-Status: No, score=-6.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 (2048-bit key) header.d=sethblank-com.20221208.gappssmtp.com
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 XjjHfQZnoiFW for <dmarc@ietfa.amsl.com>; Thu, 8 Jun 2023 07:54:39 -0700 (PDT)
Received: from mail-oa1-x32.google.com (mail-oa1-x32.google.com [IPv6:2001:4860:4864:20::32]) (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 5A925C151084 for <dmarc@ietf.org>; Thu, 8 Jun 2023 07:54:38 -0700 (PDT)
Received: by mail-oa1-x32.google.com with SMTP id 586e51a60fabf-19f9f11ba3dso614670fac.2 for <dmarc@ietf.org>; Thu, 08 Jun 2023 07:54:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sethblank-com.20221208.gappssmtp.com; s=20221208; t=1686236077; x=1688828077; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=mmhOH/kReDpMfq17g7/oad5g53oBeBl+R04Kbl7+zxU=; b=IzKYI0C+qV2DbJ8AqSP4PHluSqpJ2tiCPC/uG5pv83NZDPMSURqanMwlrZgS0E1qIJ UNrWKzVCBGNRs370VHCm/hcytpL0MsRAo6GrWA/8LcjHuLkI6CBPVMB0dMtECji76aWQ ARgtwMNZOyTw/AqQ37j0s1T2awf1oMhJQuiv+ky0OiHGL/X3mxW4RDC+sdtFKn2sA5BQ MFXywxOzXzxC5BO+t5GBB9FhVvFMUk3JxXl8gZXOo7iL4010R/3yY2vyNUHL1QaH5T6O O4/XOlDnPhMU5vE2t3HmuZAGCVYPqLhmjgci06ZzVUHDvDWYHWTuqn95rCK2NPt6A3Zr QiQA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1686236077; x=1688828077; 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=mmhOH/kReDpMfq17g7/oad5g53oBeBl+R04Kbl7+zxU=; b=bPHxPsM0l+/zZFG/up19K0ULT2uTekhiIGl5pAm3dOlBTRof+XaDhXIEuo6CzkohxB Al705aEnY9JhOmPnn84wONWZxs4TqzT44abs5UVSjQhn8MCcgf7jCVC56L45GKhiKpWx NrsBBKFsQcS8ujT9RVBGJf3xJfl6Hgj5FC3WtznzgSzqN8TXnsv1x6S6ReEYvPDEJq0x zcgUzbjAcjZaLA2TbjHIXZKHxIFXm3gx958HxHMlz7DNca2GpUwvgy6Dv5Hs/p9yyRQF qbqpIK3g7mZL9upKVgGg9sjlQSzzWVISnBzQXMj6kwzXIt/YnzoPG9pdb5gw/+q2ciPc kMRQ==
X-Gm-Message-State: AC+VfDwHHvdeuEoiNwAhL9OEZY5tuRO1soqJwaHgN81RxOgwkl0qdvR9 bKZK9z0mQbYqle/xamVzexESgWI/KfvHzQ/IFayxXLi6EmOtcMcrewg=
X-Google-Smtp-Source: ACHHUZ6k+eTuYWffj+thGgen7R+il4pYAP0SpgfGCuAHCzUg4rY1gBAEIaexulkwjbmctSNQjRmXXDMwMBaA9kBAjFw=
X-Received: by 2002:a05:6870:e14b:b0:1a2:cfd7:bfdc with SMTP id z11-20020a056870e14b00b001a2cfd7bfdcmr7561460oaa.6.1686236077449; Thu, 08 Jun 2023 07:54:37 -0700 (PDT)
MIME-Version: 1.0
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>
In-Reply-To: <CALaySJKrXJJXz3pgp85BPswoirhPJtD=uuefVfc9sX1fGkj-iA@mail.gmail.com>
From: Seth Blank <seth@sethblank.com>
Date: Thu, 08 Jun 2023 15:54:21 +0100
Message-ID: <CAD2i3WMbVZ0-yQeqoy7P9njyBRU2jdbP2jGtzUnzEE0dfsLR2g@mail.gmail.com>
To: Barry Leiba <barryleiba@computer.org>
Cc: Seth Blank <seth=40valimail.com@dmarc.ietf.org>, Tobias Herkula <tobias.herkula=401und1.de@dmarc.ietf.org>, "dmarc@ietf.org" <dmarc@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000677a2b05fd9f6e0b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/IRav_RBPIst1Y8OxKG1Wd1ldCW0>
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 14:54:40 -0000

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> 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> 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>
>> wrote:
>>
>>> On Thu, Jun 8, 2023 at 6:00 AM Tobias Herkula <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, 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
>>> _______________________________________________
>>> 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/or
>> 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 prohibited
>> and may be unlawful. Please immediately notify the sender by replying to
>> 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
>