IETF Logo Mail Archive

Re: [dmarc-ietf] SPF follies, WGLC editorial review of draft-ietf-dmarc-dmarcbis-30

Laura Atkins <laura@wordtothewise.com> Wed, 03 April 2024 09:21 UTC

Return-Path: <laura@wordtothewise.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 0CEA1C151543 for <dmarc@ietfa.amsl.com>; Wed, 3 Apr 2024 02:21:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.074
X-Spam-Level:
X-Spam-Status: No, score=-1.074 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, MISSING_HEADERS=1.021, 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
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=wordtothewise.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 6UVgY9P4v85A for <dmarc@ietfa.amsl.com>; Wed, 3 Apr 2024 02:21:10 -0700 (PDT)
Received: from mail.wordtothewise.com (mail.wordtothewise.com [104.225.223.158]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12AEDC17C8B6 for <dmarc@ietf.org>; Wed, 3 Apr 2024 02:21:07 -0700 (PDT)
Received: from smtpclient.apple (unknown [176.61.50.187]) by mail.wordtothewise.com (Postfix) with ESMTPSA id 28E5C9F513 for <dmarc@ietf.org>; Wed, 3 Apr 2024 02:21:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=wordtothewise.com; s=aardvark; t=1712136062; bh=6UCxmI5r7O3SeJlRSaR3KrO6zCB6dQHNzOliSj7n/Kw=; h=From:Subject:Date:In-Reply-To:Cc:References:From; b=mZ6MIepiL2ycuCaI7XAZiRObtCwxFtmbBRfasHIQ2emwZGSQ/UX1AGgmf14ewVOXp L0LzuEvNb8ySXjrniomRGKvYimQX6uOb50cvCne1Y0ePzqaTv1SDNJVhwCq0EkpbpA zOCNiZpFeDRX2njKrpp7MWYaGI2kD8TOSpWdUeJM=
From: Laura Atkins <laura@wordtothewise.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_A810E205-982C-40D9-BF0A-FE6CA8D59611"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.700.6.1.1\))
Date: Wed, 03 Apr 2024 10:20:50 +0100
In-Reply-To: <MN2PR11MB435115B7428C63C1B1058D9EF73F2@MN2PR11MB4351.namprd11.prod.outlook.com>
Cc: "dmarc@ietf.org" <dmarc@ietf.org>
References: <eda55c54-c149-475c-8117-bfdf3885a883@tekmarc.com> <20240331180009.F36CD8687B50@ary.qy> <CAOZAAfP9tXi80Fi=ZkgPpGwHo1fDbdSOZwVcnuPDbbc2xQd-7A@mail.gmail.com> <lIU60SB3NeCmFAG+@highwayman.com> <CAL0qLwZt+bo4ydCVOQbfg6bQEv-ufXrrwr8Aege9Wsv7LgH=kA@mail.gmail.com> <CAOZAAfPtxdBwEthN26cgvAnAbQ70wym+2k0WjtKqNVf44=-vMg@mail.gmail.com> <MN2PR11MB435115B7428C63C1B1058D9EF73F2@MN2PR11MB4351.namprd11.prod.outlook.com>
Message-Id: <E7BDAB1F-D15B-4B9F-ADCA-E63E1331542B@wordtothewise.com>
X-Mailer: Apple Mail (2.3731.700.6.1.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/skSnQTFOaiSKy2NEfEH0roUEf7U>
Subject: Re: [dmarc-ietf] SPF follies, WGLC editorial review of draft-ietf-dmarc-dmarcbis-30
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: Wed, 03 Apr 2024 09:21:14 -0000

> On 1 Apr 2024, at 13:18, Brotman, Alex <Alex_Brotman=40comcast.com@dmarc.ietf.org> wrote:
> 
> One item left out of Seth’s text is that due to MBPs who act in this fashion, these SPF evaluation failures will (understandably) not show up in DMARC reports, and the domain owner may not have visibility for these failures.  However, the text also puts the onus on the domain owner instead of the MBP.  The text could be altered to instead suggest that MBPs who deploy DMARC should not utilize the outcome of SPF in this fashion.  If the domain owner wants to protect their domain, and has no idea if the MBP supports DMARC properly (presuming they also have an enforcing policy), is it more or less advisable to use “-all” with your SPF record?

Is that true, though?

I just saw a report yesterday that someone had temp failures at Gmail (73 to be exact) and Gmail sent 73 DMARC reports for that sender / IP combo. 

So that’s one bit of evidence that even if the message is not accepted, DMARC reports are sent. 

laura

-- 
The Delivery Expert

Laura Atkins
Word to the Wise
laura@wordtothewise.com

Delivery hints and commentary: http://wordtothewise.com/blog

v2.23.0 | Report a Bug | By Email