IETF Logo Mail Archive

Re: [dmarc-ietf] DMARCbis WGLC - Issue 141 DMARC and What To Say About SPF -all

Mark Alley <mark.alley@tekmarc.com> Sun, 07 April 2024 13:07 UTC

Return-Path: <mark.alley@tekmarc.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 D5C20C14F6A2 for <dmarc@ietfa.amsl.com>; Sun, 7 Apr 2024 06:07:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.095
X-Spam-Level:
X-Spam-Status: No, score=-2.095 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_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=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=tekmarc.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 0mdFJAvc7_Ps for <dmarc@ietfa.amsl.com>; Sun, 7 Apr 2024 06:07:35 -0700 (PDT)
Received: from mail-yw1-x112a.google.com (mail-yw1-x112a.google.com [IPv6:2607:f8b0:4864:20::112a]) (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 5E5A2C14F610 for <dmarc@ietf.org>; Sun, 7 Apr 2024 06:07:35 -0700 (PDT)
Received: by mail-yw1-x112a.google.com with SMTP id 00721157ae682-617e42a3f94so13188177b3.2 for <dmarc@ietf.org>; Sun, 07 Apr 2024 06:07:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tekmarc.com; s=google; t=1712495254; x=1713100054; darn=ietf.org; h=in-reply-to:from:content-language:references:to:subject:user-agent :mime-version:date:message-id:from:to:cc:subject:date:message-id :reply-to; bh=uqTRSskGzSEm5LuDfukK1BvIIWr9+nzBk4+0z8MtSo0=; b=Akq/K4684s3bAfmyciI4iaUmgEbiXppZXiYZhF5UDmTih3JVy3oKUKwOK53UsG18z0 3jzkzHai4c0fvv/ORx2eOHDVjePL4Lmthif6Uc72cxRoCE5TeDkfeSd03nej/TbwVR6A UcP6YdJvPapeB0OK7lBUJxQ1pmYwukt1qdgyUqyBbSFGBS5We58Sfls14E87lEQKnabj O1gjimggQPFfpDz1+WvQUQQ+LzABs3/TRVDs7RDLy0VTUtI00lOZIsLjyyOXOmrHKCs8 WFY6cGOy2W1nSvcFa5nFJgGn2wvR1t9irpItwoddd7ZAEWRkMtiupoI7TZsinOM7OtOj v5dQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712495254; x=1713100054; h=in-reply-to:from:content-language:references:to:subject:user-agent :mime-version:date:message-id:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to; bh=uqTRSskGzSEm5LuDfukK1BvIIWr9+nzBk4+0z8MtSo0=; b=XbfRzIpOPPHzNVYDLwWGUFKvJ76L3S066/6Zgl1coCUHxg1w2/d2bQr9T1TZRljKZQ UgGAgfxNk+l1qyRQRYj/gv8mRjeeCi+bBLQOG/a4ISH4WMpPWKiw27TiGT5nqLCKU81G LGAGoHsOS91oEAPxi1Cbb+jI9Pxmh0yciAWsajGsq69avuOENrEJCszfr4jqAM1o4QPQ h88zXwt3Ln8ssoObwJzfucrdcmxThHLEIc5M7XWf4DrmLdevWYPBOeovBXn+u9MAEhyE YWfcHWK+f5M7TC0Z+7GnTuvuFUv72SJDa0rs28q3GG2df/sqzuMfM3DfY+zY2RZb9m2R gZ5Q==
X-Gm-Message-State: AOJu0Yx5bLKhxs0SIl6D90D9SiluysBdO2cYG8pzoEA5o1SspUkIKYi2 cuvlBuMrnv8Dqc469KYxVFG2r6OMGLABcmCO1z1LusvvZjPv3xFcG6B3xkypaw+6d+CfoYnJ25C 7
X-Google-Smtp-Source: AGHT+IEWdlMk4kvE44NyY2mKb4lb6cvN3zgMzCByZG/T3R334VOM5SAdWUAPCn2efF2V6uapGAB5KQ==
X-Received: by 2002:a81:6088:0:b0:610:f666:8251 with SMTP id u130-20020a816088000000b00610f6668251mr5654309ywb.37.1712495253732; Sun, 07 Apr 2024 06:07:33 -0700 (PDT)
Received: from [192.168.2.20] (162-238-103-217.lightspeed.brhmal.sbcglobal.net. [162.238.103.217]) by smtp.gmail.com with ESMTPSA id z8-20020a81ac48000000b00614279eeea7sm1249758ywj.68.2024.04.07.06.07.33 for <dmarc@ietf.org> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 07 Apr 2024 06:07:33 -0700 (PDT)
Content-Type: multipart/alternative; boundary="------------Xyt3Amv6Q3vZVp1cQRbm7vWT"
Message-ID: <6bc26af6-e4de-4c15-8486-a4730351ec88@tekmarc.com>
Date: Sun, 07 Apr 2024 08:07:33 -0500
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
To: dmarc@ietf.org
References: <20240406204004.348F78701D5A@ary.qy> <66A098B7-709F-4611-963F-58A344B70BA3@marmot-tech.com>
Content-Language: en-US
From: Mark Alley <mark.alley@tekmarc.com>
In-Reply-To: <66A098B7-709F-4611-963F-58A344B70BA3@marmot-tech.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/CsyUII9Rk3gpd_j4oGEA2sWpehE>
Subject: Re: [dmarc-ietf] DMARCbis WGLC - Issue 141 DMARC and What To Say About SPF -all
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, 07 Apr 2024 13:07:39 -0000

That would probably be a question better placed on the SPFbis list, and 
(IETF veterans, keep me honest) it probably wouldn't be able to be 
addressed fully unless SPFter becomes a thing at some point.

Outside of unnecessary/unexpected uses of it (due to reasons outlined 
previously in the thread), there's still valid, expected, and reasonable 
use cases of it as it stands today. Personally, I don't see a need for 
it to be deprecated.

- Mark Alley

On 4/7/2024 7:52 AM, Neil Anuskiewicz wrote:

> Forgive me if this a dumb idea but, Scott and others, any discussion of just deprecating SPF hardfail at some point?
>
>> On Apr 6, 2024, at 1:40 PM, John Levine<johnl@taugh.com>  wrote:
>>
>> It appears that Scott Kitterman<sklist@kitterman.com>  said:
>>> I hear you.  Your operational issue is my system working as designed.  DMARC
>>> works on top of SPF, it doesn't change it.
>>>
>>> Anything like this belongs in an operational guidance document, not in the
>>> protocol description.  I have no problem describing the trade offs in an
>>> appropriate document, but I don't think this is it.
>> I agree.  "Don't do stupid stuff" goes in an A/S, not in the spec.
>>
>> I entirely believe people are confused about SPF, but they're confused
>> about everything. A few days ago on the generally clueful NANOG list
>> we had to explain to someone that rejecting mail if DKIM signatures
>> don't verify is not a good idea.
>>
>> R's,
>> John
>>
>> _______________________________________________
>> 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

v2.23.0 | Report a Bug | By Email