IETF Logo Mail Archive

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

Tim Wicinski <tjw.ietf@gmail.com> Mon, 01 April 2024 16:17 UTC

Return-Path: <tjw.ietf@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 2FDFEC14CF1C for <dmarc@ietfa.amsl.com>; Mon, 1 Apr 2024 09:17:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.093
X-Spam-Level:
X-Spam-Status: No, score=-2.093 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_BLOCKED=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=unavailable 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 khzS9GRxqKmH for <dmarc@ietfa.amsl.com>; Mon, 1 Apr 2024 09:17:35 -0700 (PDT)
Received: from mail-ed1-x535.google.com (mail-ed1-x535.google.com [IPv6:2a00:1450:4864:20::535]) (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 C52ACC14CF1A for <dmarc@ietf.org>; Mon, 1 Apr 2024 09:17:35 -0700 (PDT)
Received: by mail-ed1-x535.google.com with SMTP id 4fb4d7f45d1cf-56890b533aaso4498818a12.3 for <dmarc@ietf.org>; Mon, 01 Apr 2024 09:17:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1711988254; x=1712593054; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=Gfhr5PiaJ64fC9rnbqOS93Px2+LUoxxiHueU5sG2ViE=; b=ZoIMc2ostjrrtkys8KVcFYwb9ZbImKfrgyLpL0OrVHZhmbVeNvrNlnvqklpih4IEpY 3nkCzih9FWug36EaNeSLQZE86bqdYo3glAxWOmNiB0OO/QyuqKcI0rmzaCO+STbUUPPY JbrmWR71j2UT7mN4UYGLk3TvCqRlYzoDlLCCOdsnvn+9OXEvfXdvPFHtavzL/7cq6sgn TiZ26dX9BiCt/aAKynlaepp6IKqwmBbjmGXi42PG2KX0agMwePos6IxrYfpEospxyDkP gxBA3X/Rm46R7pFJieQUGOEwdMSzHrLGHatzNqTrqCqKC0RkUqjJGBUPQpRhRzqS75WF qKYw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711988254; x=1712593054; 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=Gfhr5PiaJ64fC9rnbqOS93Px2+LUoxxiHueU5sG2ViE=; b=CF3aV5c+vAaDgiZXk1XkzCOrcX5Mi12PVf4l42XvjaINJjdX+QbMOz5M4J/BhuMXYV puDxzTprN8QBjkl0I5hyFfMNkE/Gp0VKZ6rCq1NCAXckAb6gY3CI0nYdAOe/TiGGe+hd NxOySvCdsJTo52uv+g1KTurCk2xfhGuLGYbH9CrSrSCzStmpCasg9gubgraHg0nlbs/7 w7bn+lE42RtGqh4W9+Zsr2WnROvoC4cj6xYLkpIacXnKXLXQsBREjtAsMGDHvhd42+PM hgnN89/t+N2zsDKxPR0CnUrxYntiUoS0IFqqHYNCvLq49m8jMiItdNV3yz6bez5eFF0/ gH4A==
X-Forwarded-Encrypted: i=1; AJvYcCWCHFegcaHeSXCm9K1569BMlr1o1au7CuHZEOYkHP3lgzMq2G2cH8dKpec92c6H+plaRPmTWD6H4mPhaNI39g==
X-Gm-Message-State: AOJu0YzgME+1JOJNz7CZR9meUftImaZzKraV8EnsPxpALrgLgL4tENPo 26GVK/L+ZSbifGfn9Ju/p+2C+N1lkiFcOATfhktlIBYcxb9cNEUBMU/AwHlbztQeTYCcsAhU+5l MIhej4eHUWI2/+RsOtvCZStm6XimJRPA9zcs=
X-Google-Smtp-Source: AGHT+IGp8fBiFnrMlLyT+HRGtSrQtnRv9xrCVRPCrKxRdKC7MgxcnGmViCLH2tWQX4rsVVbhBMepW7s67mCkJ+d/e8w=
X-Received: by 2002:a05:6402:27ce:b0:56d:b687:5a57 with SMTP id c14-20020a05640227ce00b0056db6875a57mr6899146ede.20.1711988254017; Mon, 01 Apr 2024 09:17:34 -0700 (PDT)
MIME-Version: 1.0
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> <CAJ4XoYfmyDykZGm9Gb1bxjz=pW_scqon3pDv-DRGHjFrnyCLoQ@mail.gmail.com>
In-Reply-To: <CAJ4XoYfmyDykZGm9Gb1bxjz=pW_scqon3pDv-DRGHjFrnyCLoQ@mail.gmail.com>
From: Tim Wicinski <tjw.ietf@gmail.com>
Date: Mon, 01 Apr 2024 12:17:22 -0400
Message-ID: <CADyWQ+HbfegU=07gNyR-5Dby_71GNim4Nq-LyFerKHk1dV0=Nw@mail.gmail.com>
To: Dotzero <dotzero@gmail.com>
Cc: "Brotman, Alex" <Alex_Brotman=40comcast.com@dmarc.ietf.org>, "dmarc@ietf.org" <dmarc@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000bd936706150b53da"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/hDb1CkgdngRu-sY5k-fS7Mw1jhc>
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: Mon, 01 Apr 2024 16:17:37 -0000

I have to agree with Seth's comments that "security teams believe an SPF
hard fail is more secure".
I've been on the receiving end of that discussion more than once.

Also, can we reference those two M3AAWG documents ?  That seems like
operational guidance.

tim


On Mon, Apr 1, 2024 at 8:55 AM Dotzero <dotzero@gmail.com> wrote:

>
>
> On Mon, Apr 1, 2024 at 8:18 AM 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?
>>
>>
>>
>> I’d be curious to see the Venn diagram of MBPs who implement SPF in this
>> fashion, and also fully support DMARC.  I feel like the MBPs who I’ve
>> encountered deploying an SPF check in this way had not at the time
>> supported DMARC.
>>
>>
>>
>> --
>>
>> Alex Brotman
>>
>> Sr. Engineer, Anti-Abuse & Messaging Policy
>>
>> Comcast
>>
>>
> I was just thinking along these lines and was going to post but you beat
> me to the punch.
>
> +1
>
> Michael Hammer
> _______________________________________________
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>

v2.23.0 | Report a Bug | By Email