Re: [dmarc-ietf] DMARCbis WGLC - Issue 135 - What To Say About Too-Permissive/Third-Party SPF and Where To Say It?

Alessandro Vesely <vesely@tana.it> Thu, 14 March 2024 16:13 UTC

Return-Path: <vesely@tana.it>
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 A131AC151064 for <dmarc@ietfa.amsl.com>; Thu, 14 Mar 2024 09:13:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.107
X-Spam-Level:
X-Spam-Status: No, score=-2.107 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, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=tana.it header.b="7UXNgATF"; dkim=pass (1152-bit key) header.d=tana.it header.b="CfFvoZhY"
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 XLLApK1cCxPT for <dmarc@ietfa.amsl.com>; Thu, 14 Mar 2024 09:13:24 -0700 (PDT)
Received: from wmail.tana.it (wmail.tana.it [94.198.96.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F4036C151063 for <dmarc@ietf.org>; Thu, 14 Mar 2024 09:13:23 -0700 (PDT)
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=tana.it; s=epsilon; t=1710432801; bh=+LuAi2IOynQv2FQm8p7Iw8j3AfYXCxDmtcQ4yZ5JN30=; h=Author:Date:Subject:To:References:From:In-Reply-To; b=7UXNgATFW+Sv3nTi9DZUqOfE3qyu1VGb7RJo3Lty7FOiTOcrpRaxm9eVMJvCWm6cY ZLI5afbRtNVnaupAGg0Dw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1710432801; bh=+LuAi2IOynQv2FQm8p7Iw8j3AfYXCxDmtcQ4yZ5JN30=; h=Date:Subject:To:References:From:In-Reply-To; b=CfFvoZhYcbbgaTSoAgy4AyalABPyOwKWoJJMqBX5HFtYQrwagNqSuD35vn2/xI743 BRVRaGT73Zm8NQ9s/NBYllP8G8jSP9xhTLO1mCCYzM1+Vk962WoFiez/qn0yLtZILx LIR3N4wH5BbujwU7Ka+tzz77w1F3SIrLwBSUejrJlyK8Ya49WfLi0S608sZy0
Original-Subject: Re: [dmarc-ietf] DMARCbis WGLC - Issue 135 - What To Say About Too-Permissive/Third-Party SPF and Where To Say It?
Author: Alessandro Vesely <vesely@tana.it>
Received: from [172.25.197.120] (pcale.tana [172.25.197.120]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.3, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC0E3.0000000065F32221.0000126F; Thu, 14 Mar 2024 17:13:21 +0100
Message-ID: <99f97d8c-94dd-4ab7-94d9-a74d8bcf7a8d@tana.it>
Date: Thu, 14 Mar 2024 17:13:20 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Content-Language: en-US, it-IT
To: dmarc@ietf.org
References: <CAHej_8nrQG3XN5k=p0x5KzV3ZLAzzGQaXNpG9cFvPS338uS0dw@mail.gmail.com>
Authentication-Results: tana.it; auth=pass (details omitted)
From: Alessandro Vesely <vesely@tana.it>
In-Reply-To: <CAHej_8nrQG3XN5k=p0x5KzV3ZLAzzGQaXNpG9cFvPS338uS0dw@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/inHty-H16UH0jtI2iP-Qy3_Q_N0>
Subject: Re: [dmarc-ietf] DMARCbis WGLC - Issue 135 - What To Say About Too-Permissive/Third-Party SPF and Where To Say It?
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: Thu, 14 Mar 2024 16:13:33 -0000

On Thu 14/Mar/2024 16:44:22 +0100 Todd Herr wrote:
> 
> Issue 135 is open for the subject topic. Please add your thoughts to this 
> thread and/or to the issue in Github.


I proposed an alternative text for section 5, Policy[*].  I repeat it here with 
an added sentence:

OLD
    A Domain Owner or PSO may choose not to participate in DMARC
    evaluation by Mail Receivers simply by not publishing an appropriate
    DNS TXT record for its domain(s).  A Domain Owner can also choose not
    to have some underlying authentication technologies apply to DMARC
    evaluation of its domain(s).  In this case, the Domain Owner simply
    declines to advertise participation in those schemes.  For example,
    if the results of path authorization checks ought not to be
    considered as part of the overall DMARC result for a given Author
    Domain, then the Domain Owner does not publish an SPF policy record
    that can produce an SPF pass result.

NEW
    A Domain Owner or PSO may choose not to participate in DMARC
    evaluation by Mail Receivers simply by not publishing an appropriate
    DNS TXT record for its domain(s).  A Domain Owner can also adjust how
    some underlying authentication technologies apply to DMARC evaluation
    of its domain(s).  To do so, the Domain Owner directly operates on
    its participation in those schemes.  For example, if the results of
    path authorization checks ought not to be considered as part of the
    overall DMARC result for a given Author Domain, then the Domain Owner
    does not publish an SPF policy record, or it can use the neutral
    qualifier to avoid granting "pass" results to external domains (that
    is, for example "v=spf1 ?include:example.com -all").  Obviously, the other
    authentication technology has to be resiliently implemented in such case.


Best
Ale
-- 
[*] https://mailarchive.ietf.org/arch/msg/dmarc/Mr0jW04HijJqeleW0sXZhWX-s3Q