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

Scott Kitterman <sklist@kitterman.com> Wed, 27 January 2021 19:24 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 D87863A0DF7 for <dmarc@ietfa.amsl.com>; Wed, 27 Jan 2021 11:24:09 -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=cD75wfC/; dkim=pass (2048-bit key) header.d=kitterman.com header.b=DngScC7X
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 O8HMnUXI-L4p for <dmarc@ietfa.amsl.com>; Wed, 27 Jan 2021 11:24:08 -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 F41493A0DEC for <dmarc@ietf.org>; Wed, 27 Jan 2021 11:24:07 -0800 (PST)
Received: from interserver.kitterman.com (interserver.kitterman.com [IPv6:2604:a00:6:1039:225:90ff:feaa:b169]) by interserver.kitterman.com (Postfix) with ESMTPS id 6A579F80263 for <dmarc@ietf.org>; Wed, 27 Jan 2021 14:24:06 -0500 (EST)
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1611775446; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=WyMXRDcUes55Y6nel3g/EawEAviAJA6pmDtMD+LM4pk=; b=cD75wfC/8FHogHzakIeFEHDgWiPFdOsU1EMwk5ywBwqFwG0PGpv6DBqygllWzEiEiwKQF FQGx2wd7zBTxM9JBg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1611775446; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=WyMXRDcUes55Y6nel3g/EawEAviAJA6pmDtMD+LM4pk=; b=DngScC7Xwv5EeptmwWgBwLcFteromS7iBCm85NZJCZVMTOlRDgbI9VIzyK/14yQEWNj/L l7ph8NBKkX01gzaA3wEAKn3tOJIf8jYAyc2/J5S8m8x6i1iscN4dxUqusZIWZPceyJXBtty 1hu52W64li/6OQkEQMtPupSGk5fNvEvsrwyPWZCUnSVTAtPdxqkHBlOBUiWE8HuXWT1U7Fi jklV7e5A/wQtkvH1aZ1zP5rgZWVYn1INrpPTtihFcl5yR/+yP6OFMxmkwKqvdTz2V/vwvUt NLde2FEvhZTqnNTiZkTdKNYg40R3xWu+2p7ixrew85Tf96a5deB54Pu4x/zg==
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 31C54F80052 for <dmarc@ietf.org>; Wed, 27 Jan 2021 14:24:06 -0500 (EST)
From: Scott Kitterman <sklist@kitterman.com>
To: dmarc@ietf.org
Date: Wed, 27 Jan 2021 14:24:05 -0500
Message-ID: <11050391.cvU1rW7NdO@zini-1880>
In-Reply-To: <81ab38a1-4b0a-3845-fc8c-7d49d7850c26@tana.it>
References: <bef64e7a-571b-a73f-dc91-aa402ca320c8@taugh.com> <3776619.NdRDDhGtae@zini-1880> <81ab38a1-4b0a-3845-fc8c-7d49d7850c26@tana.it>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/nTQIpDXlBAdqbzcbFZX4jrwSRPA>
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: Wed, 27 Jan 2021 19:24:10 -0000

On Wednesday, January 27, 2021 12:25:59 PM EST Alessandro Vesely wrote:
> On Wed 27/Jan/2021 15:00:29 +0100 Scott Kitterman wrote:
> > On Wednesday, January 27, 2021 4:49:02 AM EST Alessandro Vesely wrote:
> >> On Tue 26/Jan/2021 23:36:19 +0100 Scott Kitterman wrote:
> >>> On Tuesday, January 26, 2021 11:47:51 AM EST Alessandro Vesely wrote:
> >>>> On Tue 26/Jan/2021 14:14:45 +0100 Scott Kitterman wrote:
> >>>>> On Tuesday, January 26, 2021 6:54:56 AM EST Alessandro Vesely wrote:
> >>>>>> I doubt that SPF filters report envelope-from=postmaster@HELO; more
> >>>>>> likely they write helo=HELO.  In that case, the paragraph quoted
> >>>>>> above
> >>>>>> is deceptive.
> >>>>>> 
> >>>>>>> I believe the proposed text is clear enough about not using
> >>>>>>> separate HELO identity results and that's appropriate. >>>>
> >>>>>> 
> >>>>>> My filter collects SPF results recorded from an upstream SPF filter.
> >>>>>> It writes Received-SPF: lines for each identity.  For NDNs, it writes
> >>>>>> a Received-SPF: for the HELO identity only.  Am I allowed to use that
> >>>>>> result for DMARC?
> >>>>> 
> >>>>> No.  You should only use Mail From results.
> >>>> 
> >>>> So NDNs having only an aligned HELO will never pass DMARC?
> >>>> 
> >>>> And what is a <scope>helo</scope> element in aggregate reports provided
> >>>> for?
> >>>> 
> >>>> The spec says:
> >>>>           [SPF] can authenticate either the domain that appears in the
> >>>>     
> >>>>     RFC5321.MailFrom (MAIL FROM) portion of [SMTP] or the RFC5321.EHLO/
> >>>>     HELO domain, or both.
> >>>> 
> >>>> And then:
> >>>>     In relaxed mode, the [SPF]-authenticated domain and RFC5322.From
> >>>>     domain must have the same Organizational Domain.  In strict mode,
> >>>>     only an exact DNS domain match is considered to produce Identifier
> >>>>     Alignment.
> >>>> 
> >>>> So, consider the following message without DKIM signatures:
> >>>> 
> >>>> HELO example.org
> >>>> MAIL FROM:<user@example.com>
> >>>> 
> >>>> Received-SPF: pass (domain example.org
> >>>> 
> >>>>    designates 192.0.2.1 as permitted sender)
> >>>>    identity=helo; helo=example.org;
> >>>> 
> >>>> Received-SPF: fail (domain of user@example.com
> >>>> 
> >>>>    denies 192.0.2.1 as permitted sender)
> >>>>    identity=mailfrom; envelope-from="user@example.com".com";
> >>>> 
> >>>> Subject: Not using a mail client for this example
> >>>> From: different-user@example.org
> >>>> 
> >>>> Does it pass DMARC?
> >>> 
> >>> No.
> >> 
> >> Let's not be silly, Scott.  We have example.org as the SPF-authenticated
> >> domain and it is aligned with From:.  Are you saying that the message
> >> would pass if it had an empty bounce address, but since it can bounce it
> >> does not pass?!? >
> > 
> > All I'm saying is that DMARC only uses mail from results and that's
> > appropriate.  I don't think the case of HELO name being aligned, but mail
> > from domain is not is one to worry about.
> 
> That's abnormal, not appropriate.
> 
> AFAIUI, there's no reason why SPF would work with a logic substantially
> different than DKIM's.  DKIM can provide n identifiers, if one of them is
> aligned and "pass", then DMARC is "pass".  SPF can provide 2 identifiers but
> one of them is of class B.  WTF?
> 
> Can anyone explain why we have a <scope>helo</scope> element in aggregate
> reports?
> 
> Can we fix this aberration?
> 
> The spec needs a fix anyway, because from the text I quoted above I
> understood that the example message passes DMARC.  Am I the only one?
> 
> In addition, as I said, SPF filters are likely to report HELO as helo and
> MAIL FROM as mailfrom.  If we want to carry over this quirk, the spec must
> say that a DMARC filter which gathers SPF authentication status from an
> upstream filter MUST make sure that mailfrom is empty before validating
> based on an aligned helo.
> 
> Dropping that absurd discrimination between SPF identifiers would make for a
> smoother spec.  Since non-null mailfroms are in most cases aligned with
> either From: or helo, the differences between existing compliant
> implementations and the smoother spec would be limited to a hardly
> noticeable set of test messages.

Your absurd is my eminently reasonable.

I can't explain why it was added, but it makes sense, IMO, to have it there to 
aid in reconstructing the exact situation for trouble shooting purposes.

DMARC has always (for the SPF related portion) been about alignment of mail 
from and from.  I don't think adding HELO has appreciable value and is 
certainly not worth the added complexity to implement DMARC to include.

There are lots of ways that DMARC could have addressed SPF.  Personally I 
thought it might make sense to skip using the mail from SPF result and just 
check if the from address would pass if it were subjected to an SPF check, but 
that's not the existing design.  I don't think it should be changed now.

That said, I agree it's not 100% clear.  I too am interested in what others 
think.

Scott K