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

Tero Kivinen <kivinen@iki.fi> Sun, 07 April 2024 13:54 UTC

Return-Path: <kivinen@iki.fi>
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 5CAA3C14F685 for <dmarc@ietfa.amsl.com>; Sun, 7 Apr 2024 06:54:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.163
X-Spam-Level:
X-Spam-Status: No, score=-4.163 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, NICE_REPLY_A=-2.064, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=iki.fi
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 iiu8LBnRrN1I for <dmarc@ietfa.amsl.com>; Sun, 7 Apr 2024 06:53:58 -0700 (PDT)
Received: from meesny.iki.fi (meesny.iki.fi [195.140.195.201]) (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 681F0C14F610 for <dmarc@ietf.org>; Sun, 7 Apr 2024 06:53:57 -0700 (PDT)
Received: from fireball.acr.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (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) (Authenticated sender: kivinen@iki.fi) by meesny.iki.fi (Postfix) with ESMTPSA id 4VCDGV0wk0zyTF; Sun, 7 Apr 2024 16:53:54 +0300 (EEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=meesny; t=1712498034; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=egTEfcqpwMebeFZxACt2dWGYxD72jIPO9ufVy/jOUM0=; b=TC58h53pblJfQweydMBAvyMZ4hNrzRQYKsrDqt89z83l5lkAetoo2eDL4CD8nYR7n1Wvjk XQp3YGTs1Sdf1RwrITZUqul8/Qx7Pj/s0BMHO6UB+Xg+vi8IzpffGg0qkzOanCLeZ18XDl VBwvS87vQ6AOAfKgpoyMyPrifVJMJRM=
ARC-Seal: i=1; s=meesny; d=iki.fi; t=1712498034; a=rsa-sha256; cv=none; b=Rd+X7u5OGwo3wJuJKYjDVCvPz1NTe5C96ntxAWD/6aRYXT6nK/ALEqx2Me3jT5sCM8YIM2 WCOchf3kRwOR8un6tw9XztjyHyilUY199hH5sRMpjtuX2HQS9QXKHEkCtfNNJbjjcQfK9R nq2DVF8KPuG0juyQ4dBZGxf28CEw5aI=
ARC-Authentication-Results: i=1; ORIGINATING; auth=pass smtp.auth=kivinen@iki.fi smtp.mailfrom=kivinen@iki.fi
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=meesny; t=1712498034; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=egTEfcqpwMebeFZxACt2dWGYxD72jIPO9ufVy/jOUM0=; b=jkBE0snbGOezt3VuLB+Dspis3Wfsjl/Yu9pG2E+M9ZDMW+R4fyarkWLIh7tYqty3BFVblF ActYx9rBFsaMBqXnIB4/ikULe+a2RfM6wIqm5AU20PxxEngTdQnWB8QoiSsEv4PRU8B3Jn hn2MrK9NsehBOU4J+VSSKSZ4QE/3+So=
Received: by fireball.acr.fi (Postfix, from userid 15204) id 6C56925C130F; Sun, 7 Apr 2024 16:53:53 +0300 (EEST)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID: <26130.42353.390864.725688@fireball.acr.fi>
Date: Sun, 07 Apr 2024 16:53:53 +0300
From: Tero Kivinen <kivinen@iki.fi>
To: Scott Kitterman <sklist@kitterman.com>
Cc: dmarc@ietf.org
In-Reply-To: <10772164.eV7dEhVGUO@zini-1880>
References: <CAHej_8=te5Zx_5-rB67CLPy_Eh03H6bE=34T-sTAwwmnvRTqWg@mail.gmail.com> <2791156.Tha2kTCVin@zini-1880> <CAOZAAfNkz6wu_ZOUR7-iojreAzTHONnC600SnTLArHd+EK28ag@mail.gmail.com> <10772164.eV7dEhVGUO@zini-1880>
X-Mailer: VM 8.2.0b under 26.3 (x86_64--netbsd)
X-Edit-Time: 6 min
X-Total-Time: 5 min
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/LIFE5EG6MY7ijBxPuaaWr2WC2cA>
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:54:03 -0000

Scott Kitterman writes:
> I hear you. Your operational issue is my system working as designed.
> DMARC works on top of SPF, it doesn't change it.

Yes, DMARC works on top of SPF, and DKIM and provides policy layer. We
are trying to change the fact that people rely purely on SPF, and try
to get them moved to use DMARC istead, and we are trying to explain
that if you do SPF inside the DMARC context, you get exactly same
policy results you get as when you do SPF before, except you get it
better, as you have more data available. Using -all would be
completely ok if everybody would be doing DMARC, but as there are some
systems which do SPF outside DMARC, and there having -all might
shortcircuit DMARC out from the equation, we should provide guidance
to those people how they can get best results in current environment.
Thus the best current practice should be use to use ~all instead of
-all if you are trying to use DMARC, and want other systems to
actually act based on your DMARC policy. 

> 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.
> 
-- 
kivinen@iki.fi