IETF Logo Mail Archive

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

Hector Santos <hsantos@isdg.net> Sun, 18 June 2023 02:50 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 DCEC0C151552 for <dmarc@ietfa.amsl.com>; Sat, 17 Jun 2023 19:50:31 -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=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isdg.net header.b="dj4El9o0"; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b="2umVcnqB"
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 UZgYA1-Ni_t6 for <dmarc@ietfa.amsl.com>; Sat, 17 Jun 2023 19:50:27 -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 91178C15153D for <dmarc@ietf.org>; Sat, 17 Jun 2023 19:50:27 -0700 (PDT)
DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha256; c=simple/relaxed; l=6086; t=1687056623; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:From:Subject:Date:To: Message-Id:Organization:List-ID; bh=ZXktk/YxoLcRXfEmU1nrgOA59hfD XK/6edGbpvV/Vmw=; b=dj4El9o0n/xDbeMkAmksY5JaQcFe8+5otSGenJxNc6Pf sCzWm2dQVU1cC9KHtQgpckqZAqiU4/EFr5gh4IHW2SgWln1pX5+MZElBeAukyyV1 J5stVVn+eh2WWed7HKSPBzJjOVMpyAC/oSjAQ47uOmZyknG8KbyC3tareUK9K/A=
Received: by winserver.com (Wildcat! SMTP Router v8.0.454.13) for dmarc@ietf.org; Sat, 17 Jun 2023 22:50:23 -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 3154350302.1.2636; Sat, 17 Jun 2023 22:50:22 -0400
DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=6086; t=1687056619; h=Received:Received:From: Subject:Date:To:Message-Id:Organization:List-ID; bh=ZXktk/YxoLcR XfEmU1nrgOA59hfDXK/6edGbpvV/Vmw=; b=2umVcnqB1PSS10VCtETibi5Awd+k vnRUYQR/KugxhYvedMdlHwp51VgsHupgsd/VNloGi2TRUgzulWr6Zfjjcl8Y5Bco dSWHzs8q7fn0Z39+96v9rv8JMTlvF/9HdewVmia9SY3XuNr/uul0BaJwB5Z/AixK gHWRZlUZBZtlweQ=
Received: by beta.winserver.com (Wildcat! SMTP Router v8.0.454.12) for dmarc@ietf.org; Sat, 17 Jun 2023 22:50:19 -0400
Received: from smtpclient.apple ([75.26.216.248]) by beta.winserver.com (Wildcat! SMTP v8.0.454.12) with ESMTP id 3600401020.1.12340; Sat, 17 Jun 2023 22:50:18 -0400
From: Hector Santos <hsantos@isdg.net>
Content-Type: multipart/alternative; boundary="Apple-Mail=_1667591F-DE9F-41C3-ACF5-AA175BA4FCF7"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.400.51.1.1\))
Date: Sat, 17 Jun 2023 22:50:07 -0400
References: <20230618015012.DAB83F2E1699@ary.qy>
To: IETF DMARC WG <dmarc@ietf.org>
In-Reply-To: <20230618015012.DAB83F2E1699@ary.qy>
Message-Id: <9D24F07C-5CFA-49C3-867C-0617E3184C7F@isdg.net>
X-Mailer: Apple Mail (2.3731.400.51.1.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/jLAyuwl4eB4i1hZr54T3wNvMrlI>
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: Sun, 18 Jun 2023 02:50:31 -0000


> On Jun 17, 2023, at 9:50 PM, John Levine <johnl@taugh.com> wrote:
> 
> It appears that Hector Santos  <hsantos@isdg.net> said:
>>> Can these senders not accomplish the same thing by removing the SPF record altogether?
>>> 
>>> -MSK, participating
>> 
>> 
>> Isn’t SPF, DKIM and alignment are all required for DMARC1 passage? Failure if any are missing?
> 
> No, that has never been the case.  Please reread RFC 7489.
> 



Everything in that doc, all angles of reading this Informational Status RFC suggest SPF is a natural part of the DMARC consideration.  

A domain with a DMARC1 record is expected to have SPF and DKIM.  The authenticated identifiers need to be aligned as well. The DMARC1 policy define how failures are handled.  If the policy p=none allows for failures by not having a SPF record, I would agree that would be technically true but not all receivers behave the same.    With restrictive DMARC policies. SPF is pretty much required.  Senders risked failures by receivers who may applied it inconsistently. 

Section 4.3 has items 1,6, 7 and 8 describing SPF as a factor  in the established procedure and flow and consideration in policy result evaluation. 

Let’s consider the huge industry DMARC marketing as well where SPF, DKIM are described as necessary email security preparation for  DMARC.

The section 10.1, 2nd para confirms my main point that SPF may be processed separately for reject (-all)  results preempting payload processing:


   Some receiver architectures might implement SPF in advance of any
   DMARC operations.  This means that a "-" prefix on a sender's SPF
   mechanism, such as "-all", could cause that rejection to go into
   effect early in handling, causing message rejection before any DMARC
   processing takes place.  Operators choosing to use "-all" should be
   aware of this.


Anyway, I support removing SPF from the DMARCbis or DMARC2 evaluation.  Section 10.1 2nd para semantics need to remain.

Thanks

—
HLS

v2.23.0 | Report a Bug | By Email