Re: [dmarc-ietf] Ticket #1 - SPF alignment

Scott Kitterman <sklist@kitterman.com> Thu, 11 February 2021 13:50 UTC

Return-Path: <sklist@kitterman.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 017083A15F6 for <dmarc@ietfa.amsl.com>; Thu, 11 Feb 2021 05:50:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=kitterman.com header.b=zw+OOkbJ; dkim=pass (2048-bit key) header.d=kitterman.com header.b=Xk+yS4g7
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZbTCi-RHLtlf for <dmarc@ietfa.amsl.com>; Thu, 11 Feb 2021 05:50:45 -0800 (PST)
Received: from interserver.kitterman.com (interserver.kitterman.com [64.20.48.66]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49A493A15F5 for <dmarc@ietf.org>; Thu, 11 Feb 2021 05:50:45 -0800 (PST)
Received: from interserver.kitterman.com (interserver.kitterman.com [64.20.48.66]) by interserver.kitterman.com (Postfix) with ESMTPS id 2CE61F802E4 for <dmarc@ietf.org>; Thu, 11 Feb 2021 08:50:43 -0500 (EST)
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1613051442; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=lNDQke2ySePIjb7nMK9R5FJbucmC4t80KHZcb710aV4=; b=zw+OOkbJx/HIMrsFFoJ8BRkmwtUg18dvOnpqmrJc8aHoGqVpTmKEg9u0zP6n1mr3TK+Iu xTz7hNS/2M3G2S3Bg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1613051442; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=lNDQke2ySePIjb7nMK9R5FJbucmC4t80KHZcb710aV4=; b=Xk+yS4g7yegZBxRKzSn8owIuKySLUBC4LbtcrzopaRDiSQt5aDU/xyOjcAQARh/hqZXAE riEixM4pykYkxYjObnoBc67uZ4Ss96zWreG7luPUGcaxl3K82sLqDhqLcPrrHCFqJewCkdR UV7krjeqobj+gpQfiUgFhIRCJXFtxvwebCMV6pExpI8buZI7PyPJWxJGJv1WkqOeb0jNUFU 29yaFqgAGkJl/z3BywPUMyGFHe1SVmDr0R7TN0Q3of9n78WyFIXkYGL5YEjCGAmLzVpXUZT nWtHHPbMZ1dhqrLdceLJ+l1wTr/4UqNHJr8io/kX5g8DqfMtV1oO1LFFNkqQ==
Received: from zini-1880.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) by interserver.kitterman.com (Postfix) with ESMTP id D38B6F80026 for <dmarc@ietf.org>; Thu, 11 Feb 2021 08:50:42 -0500 (EST)
From: Scott Kitterman <sklist@kitterman.com>
To: dmarc@ietf.org
Date: Thu, 11 Feb 2021 08:50:42 -0500
Message-ID: <5450463.gl6gDTMLP0@zini-1880>
In-Reply-To: <CAH48ZfwG+7t+inQ7-ijH71buUfTsYFtNPBvsCT266v8Yk0HDOg@mail.gmail.com>
References: <20210203181226.9AB746D51182@ary.qy> <0d7de3eb-5b14-510c-cb4a-c78bc34610d8@gmail.com> <CAH48ZfwG+7t+inQ7-ijH71buUfTsYFtNPBvsCT266v8Yk0HDOg@mail.gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/pX07-gLFX_o8bV2kGU_DfgjbXJU>
Subject: Re: [dmarc-ietf] Ticket #1 - SPF alignment
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
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, 11 Feb 2021 13:50:47 -0000

What problem are you purporting to solve?

By problem, I mean a case were a bad actor can get a DMARC pass result if SPF 
HELO results are allowed to be used that they couldn't already get with a mail 
from result.

I don't think such a case exists which is why I think this entire line of 
argument is a waste of time.

Scott K

On Thursday, February 11, 2021 6:35:49 AM EST Douglas Foster wrote:
> Applying SPF to DMARC could become out of scope, if we choose to remove SPF
> from DMARC and make it dependent only on DKIM.   Until then, we need to
> have a shared understanding of how SPF is applied.  This question asks
> whether that shared understanding exists.
> 
> SPF involves two tests, which can be used together.   This WG can insist
> that for DMARC purposes, only one can be used:
> 
>     "When the sender is not null, DMARC-evaluation only considers the SPF
> evaluation of the MAILFROM Address.   SPF evaluation of HELO MUST NOT be
> considered for DMARC purposes."
> 
> This wording seems implied by the current language, and by those who want
> to leave it untouched.  Implication is different from specification, so our
> document should make this explicit.   Unfortunately, an explicit MUST NOT
> requirement is hard to justify.   When two domains are involved, and both
> domains have published policy information, what justification exists for
> ignoring some of the available security-related information?
> 
> If we back away from MUST NOT, then we have to consider that some
> recipients MAY evaluate SPF HELO and SPF MAILFROM together, just as the SPF
> RFC expected them to be used, and as outlined in one of my examples.    If
> some recipients MAY evaluate HELO, then senders SHOULD take care to ensure
> that HELO will generate a PASS.   Our language becomes something like this:
> 
>     "When the sender is not null, DMARC-evaluation always uses the SPF
> evaluation of the MAILFROM Address.   Some recipients may evaluate SPF HELO
> as well.   To maximize recipient trust, senders SHOULD publish an SPF
> policy which ensures that both MAILFROM and HELO will produce SPF PASS
> results."
> 
> DF
> 
> On Wed, Feb 10, 2021 at 6:29 PM Dave Crocker <dcrocker@gmail.com> wrote:
> > On 2/10/2021 3:24 PM, Douglas Foster wrote:
> > > Huh?  Are you asserting that SPF MAILFROM and SPF HELO are
> > > interchangeable?   They are not, but they can work together.
> > 
> > Perhaps I misread, but I thought I saw that this really is out of scope
> > for this working group.
> > 
> > 
> > d/
> > 
> > --
> > Dave Crocker
> > dcrocker@gmail.com
> > 408.329.0791
> > 
> > Volunteer, Silicon Valley Chapter
> > American Red Cross
> > dave.crocker2@redcross.org