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

Scott Kitterman <sklist@kitterman.com> Mon, 01 February 2021 00:10 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 0E6F73A1420 for <dmarc@ietfa.amsl.com>; Sun, 31 Jan 2021 16:10:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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_HELO_FAIL=0.001, 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=qSlqrajB; dkim=pass (2048-bit key) header.d=kitterman.com header.b=NtZ+G1Mm
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 YeWi35F6Au6U for <dmarc@ietfa.amsl.com>; Sun, 31 Jan 2021 16:10:03 -0800 (PST)
Received: from interserver.kitterman.com (interserver.kitterman.com [IPv6:2604:a00:6:1039:225:90ff:feaa:b169]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1488F3A141B for <dmarc@ietf.org>; Sun, 31 Jan 2021 16:10:02 -0800 (PST)
Received: from interserver.kitterman.com (interserver.kitterman.com [64.20.48.66]) by interserver.kitterman.com (Postfix) with ESMTPS id B9865F80295 for <dmarc@ietf.org>; Sun, 31 Jan 2021 19:10:01 -0500 (EST)
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1612138201; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=JJ9q+7I8qJ6vx29dQ7hcaIJg5oGBj/dmeKs5ZFy3GbQ=; b=qSlqrajB8TjQZZveUoSTOtysYsrHFdiD+urJaXCxaFIPeHEKiy/I1C0rf8CG56VR+sJ+d rmkiZfGFM1JCO1mDA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1612138201; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=JJ9q+7I8qJ6vx29dQ7hcaIJg5oGBj/dmeKs5ZFy3GbQ=; b=NtZ+G1MmPk7MvQaS872v5Lp+KEVKeLWDdjnQOPYOoDpjIantw5xgfe4TJp6A65T86cBtX FSnsVEdqtpcnKF+fGdPort47DZ/KUk95meJN3SnaemNyb4Xq6BSe/axyaXOhZu2RpI6sSAy CxSgwJwqtjwJpFf6heW06AqHLCNAgISCAfe5kx75M+hOF7srQwYgNEJCYxyt5xWV4MppwN9 5GDBnuTtyZYJULjHgN4Zazhn/i3Ukm4Af07EzXlBCAML57WeEktrUVnDcDK8RQaSgsFf+45 QFg0td6nTqYtMBjwjkFxcqHoKGlkfm9P986q9/jKHlPP23uRhzD/vXynTUAg==
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 7F511F80208 for <dmarc@ietf.org>; Sun, 31 Jan 2021 19:10:01 -0500 (EST)
From: Scott Kitterman <sklist@kitterman.com>
To: dmarc@ietf.org
Date: Sun, 31 Jan 2021 19:10:01 -0500
Message-ID: <1654196.ygyh55z74P@zini-1880>
In-Reply-To: <CAH48ZfwBKyA-TwSrr2422zmMO8wr1CKf2MiQZ3KvQu2hOH=_CA@mail.gmail.com>
References: <20210130212339.447316D04763@ary.qy> <36a1c70-875d-89c8-7e95-a32324654275@taugh.com> <CAH48ZfwBKyA-TwSrr2422zmMO8wr1CKf2MiQZ3KvQu2hOH=_CA@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/qRSbgEg6l7AaNWUYApzJle6uBz4>
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: Mon, 01 Feb 2021 00:10:06 -0000

I think that we're well past learning anything new in this thread.

SPF is what it is (RFC 7208).  DMARC doesn't need to re-invent the protocol 
(and shouldn't).  For any properly implemented SPF verifier, DMARC should be 
able to consume the Mail From result.  End of story.

I'd suggest close the ticket and move on.

Scott K

On Sunday, January 31, 2021 2:03:45 PM EST Douglas Foster wrote:
> I don't see any justification for using HELO unless the SMTP address is
> null.  If the SPF RFC says otherwise, this should be corrected.   Proving
> that the server domain can be tied to the IP address does nothing to prove
> that the SMTP address can be tied to the Source IP.
> 
> For DMARC, HELO is only useful if the message's From domain and the
> server's HELO domain are aligned.  A high percentage of email domains use
> servers from a different DNS domain, so this will only be true on an
> exception basis..   Consequently, software products that apply DKIM
> signatures to messages MUST be able to them to automatic messages as well.
>  Once developers provide MTA and mailstore products which service the needs
> of hosted domains, then users of non-hosted domains will be able to sign
> their automatic messages as well.   Ergo, any supposed need for HELO with
> DMARC will go away.
> 
> DF
> 
> On Sun, Jan 31, 2021 at 11:52 AM John R Levine <johnl@taugh.com> wrote:
> > On Sun, 31 Jan 2021, Alessandro Vesely wrote:
> > > One way to interpret RFC 7489 is that you can put dmarc=pass based on
> > 
> > the
> > 
> > > helo identity *only if* MAIL FROM is null.
> > 
> > That would be consistent with 7489.
> > 
> > Sec 3.1.2 says
> > 
> >     Note that the RFC5321.HELO identity is not typically used in the
> >     context of DMARC (except when required to "fake" an otherwise null
> >     reverse-path), even though a "pure SPF" implementation according to
> >     [SPF] would check that identifier.
> > 
> > But then 4.1 says
> > 
> >     o  [SPF], which can authenticate both the domain found in an [SMTP]
> >     
> >        HELO/EHLO command (the HELO identity) and the domain found in an
> >        SMTP MAIL command (the MAIL FROM identity).  DMARC uses the result
> >        of SPF authentication of the MAIL FROM identity.  Section 2.4 of
> >        [SPF] describes MAIL FROM processing for cases in which the MAIL
> >        command has a null path.
> > 
> > That section of 7208 says that if there's a null bounce address, SPF
> > pretends that the MAIL FROM was postmaster@HELO.
> > 
> > If we want, we can say not to use the SPF HELO identity, but that would be
> > an incompatible change to 7489 and I suspect would not match what most
> > DMARC checking code does.
> > 
> > Regards,
> > John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY
> > Please consider the environment before reading this e-mail. https://jl.ly
> > 
> > _______________________________________________
> > dmarc mailing list
> > dmarc@ietf.org
> > https://www.ietf.org/mailman/listinfo/dmarc