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

Douglas Foster <dougfoster.emailstandards@gmail.com> Tue, 20 June 2023 11:22 UTC

Return-Path: <dougfoster.emailstandards@gmail.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 7C518C151546 for <dmarc@ietfa.amsl.com>; Tue, 20 Jun 2023 04:22:51 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, 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] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 oQ2olsWRq_kE for <dmarc@ietfa.amsl.com>; Tue, 20 Jun 2023 04:22:50 -0700 (PDT)
Received: from mail-lj1-x22d.google.com (mail-lj1-x22d.google.com [IPv6:2a00:1450:4864:20::22d]) (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 E08C0C151071 for <dmarc@ietf.org>; Tue, 20 Jun 2023 04:22:50 -0700 (PDT)
Received: by mail-lj1-x22d.google.com with SMTP id 38308e7fff4ca-2b45bc83f26so61686491fa.0 for <dmarc@ietf.org>; Tue, 20 Jun 2023 04:22:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1687260168; x=1689852168; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=QYyKJYTZ78G4y9N4lQlIwuk5pjc7JpYR1qB3T/XU4/c=; b=pLkQs4SRhBq+wrPNsulTCOUoENJHRg1OlrlDdi0CKwJPrlKn81mLGrTBgno+QrSzkE viNyFl0riu6aW3lS6ZoQmhyJnBbrayLm8iE0md8Ba7b2N3LotFlkuXbW2VrOObxYalLX AL/lqCPBMkDXtneW5gbN8NOZSfC1VkExaJ1butE99oRSkSekrxo6lkbNGiAE4j9JgFUH VT6z7x/Uf9cwyS4LSp1RQyesSHEOAvctMVmESm3ZxgQ+bhby+yfQ1Itg8ovzkoV2Cp8a KGoDjAZxjfeOII+ZZ5RCfzmIUv66sK42oUI3EObUwmqjw/B3n6PNfj1yQbuWjMS3MrO0 llyA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1687260168; x=1689852168; h=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=QYyKJYTZ78G4y9N4lQlIwuk5pjc7JpYR1qB3T/XU4/c=; b=TKjpG8kymErPrqXztlE9ZzxoL8YJf68Gujv18qIy4U+oUjJ1ML5w7c9BOda2n0E8Hk Qu2FfuL1ALyNsY3jEmr9GTnotygUmiffkTS4dDZcGPqVgDtkgifuab8bu8rdhjj/njls hzgRsZUZgmuWvQuSF0uLBdBHzmn8FlXOt65OYBXa4RDTLlrFOH4Fr3HRe1U0D2YWQdVC 4toHiRM9pX16MA1VsAGl3qTebHEkNxWKUWMdP8d4WTCueBYXeUMSxoo+nIKY2vNpF1pv Nbn5iOzFSEwMqwIOBwKzb/3ofPO57J8ahxf53GNRq1gVeb9AA5MkxFRGWkdUg7K1Csw2 Qb4w==
X-Gm-Message-State: AC+VfDz1Cvj216F0YT0M79DA7BEDUM72FQMhy8ENRxTVBKP/jglhpY0I GhFMoiRX8SkSuooE3fyPvhulTlG066c7Bw6GetvdO3Fd
X-Google-Smtp-Source: ACHHUZ7McjrJrKv4DuhSbME8FT6HFeHL4Mk4/Ji1so/gitaVP+3DmsKf+eqq8fZmtYf5cXWMt9Px8qaz+ADw/iLb1Vg=
X-Received: by 2002:a2e:330f:0:b0:2b4:7281:1987 with SMTP id d15-20020a2e330f000000b002b472811987mr3937825ljc.44.1687260168000; Tue, 20 Jun 2023 04:22:48 -0700 (PDT)
MIME-Version: 1.0
References: <30BB83B2-B454-41B8-992B-8E2569802D9C@1und1.de> <D225D7FC-C570-4B63-A694-9F16DB1F33E1@kitterman.com> <CALaySJKwuOK-81dW2H9dtURxa5mLQDUNo+MWcs+Hho8N+yP9qg@mail.gmail.com> <2817813.dRqVH37e0G@localhost> <CALaySJJbPFBAV_7mZaARYWuMzuX+74r2Cm0jD+z92_iuFRn_MQ@mail.gmail.com> <25736.57534.195344.782189@fireball.acr.fi> <1ec42959-977a-9ce0-907a-83a5eb2b6ef2@tana.it> <25739.5435.550786.601699@fireball.acr.fi> <25739.33240.127804.524371@fireball.acr.fi> <5d9a0b0f-8777-2494-d779-376c6ab8b37d@tana.it> <7d39aa8e-dacc-05fa-eff1-2cc350d521db@inboxsys.com> <CAH48ZfwyBwfKzG_3R5uyV6tmY0yUtWy=5yAoAOEhUGn_Rz6HNw@mail.gmail.com> <47b8a0c7-6a52-a4ad-e98e-8cb2f881713e@inboxsys.com> <285f2d2e-13fd-7cdc-c816-fba759f0745b@dusatko.org> <CAH48ZfzhyZK3RQHXH-PPk=sqY9gOtpA85vV-Myyo_RrEvOGu-Q@mail.gmail.com> <CAEYhs4F9=GDsCuQ9pAi8z-MBNHUJ9jZCwipT3Qe_YjaD65s9mA@mail.gmail.com> <CAL0qLwaoie+6h2QWXF98TBBwYpN8fYf5O_Mr49YtG2vnAppgnw@mail.gmail.com> <a30eecc64ff6421ba6a88f0533837028@1und1.de>
In-Reply-To: <a30eecc64ff6421ba6a88f0533837028@1und1.de>
From: Douglas Foster <dougfoster.emailstandards@gmail.com>
Date: Tue, 20 Jun 2023 07:22:38 -0400
Message-ID: <CAH48ZfyX-Bu6dAcdCePqrgh+=DEaYYAFYC2oh98hNpscazZ2bQ@mail.gmail.com>
To: IETF DMARC WG <dmarc@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000f51a8e05fe8dde08"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/q-EPA9ELqDk_sshA2RKuP9ygfhk>
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: Tue, 20 Jun 2023 11:22:51 -0000

Currently, domain owners can disable SPF by removing their SPF policy,
which can run into the problems that you raise, with evaluators that only
understand SPF.    But providing an authentication selector in the DMARC
policy would remedy that risk.  Evaluators who understand DMARC would use
the new DMARC policy clauses to ignore SPF, but the domain owner could
still publish an SPF policy as a fallback authentication mechanism for
those evaluators who are rudimentary.

Fixing SPF:

SPF purports to tell two things:
- which server organizations are allowed to send on my behalf, and
- which servers within those organizations have that authorization

The intra-organization filter provides more granularity, but creates all of
the SPF complexity.  I suggest that intra-organization filtering is the
responsibility of the server organization, not the evaluator.

A simpler rule would be to specify the server domains that are allowed to
send on my behalf.   A message is authenticated for SPF when the server
domain (HELO or REVDNS) is in the authorized domain list and the server
host name is forward-confirmed to the Source IP.   Nested includes would
not be needed, and policies would not be excessively complex.

DF


On Tue, Jun 20, 2023 at 5:12 AM Tobias Herkula <tobias.herkula@1und1.de>
wrote:

> Sadly they can’t, there are Mailbox Providers that expect SPF Records, so
> to maintain deliverability to those, you have to keep SPF records in place
> and can’t switch to an DKIM only DMARC.
>
>
>
> / Tobias
>
>
>
> *From:* dmarc <dmarc-bounces@ietf.org> *On Behalf Of * Murray S. Kucherawy
> *Sent:* Sunday, June 18, 2023 2:42 AM
> *To:* Ken Simpson <ksimpson@mailchannels.com>
> *Cc:* Douglas Foster <dougfoster.emailstandards@gmail.com>; Jan Dušátko
> <jan=40dusatko.org@dmarc.ietf.org>; dmarc@ietf.org
> *Subject:* Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal
>
>
>
> On Sat, Jun 17, 2023 at 2:40 PM Ken Simpson <ksimpson@mailchannels.com>
> wrote:
>
> FWIW, I'd like to chuck my hat in the ring on the side of removing SPF
> from the next iteration of DMARC. As the operator of an email delivery
> service with tens of millions of primarily uncontrolled senders on web
> hosting servers, it would be *great* if domain owners could assert via
> their DMARC record that receivers should only trust DKIM-signed email.
>
>
>
> Can these senders not accomplish the same thing by removing the SPF record
> altogether?
>
>
>
> -MSK, participating
>