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

Jim Fenton <fenton@bluepopcorn.net> Tue, 02 February 2021 19:42 UTC

Return-Path: <fenton@bluepopcorn.net>
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 E483E3A110F for <dmarc@ietfa.amsl.com>; Tue, 2 Feb 2021 11:42: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_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bluepopcorn.net
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 vyL2z2NKwXbE for <dmarc@ietfa.amsl.com>; Tue, 2 Feb 2021 11:42:05 -0800 (PST)
Received: from v2.bluepopcorn.net (v2.bluepopcorn.net [IPv6:2607:f2f8:a994::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5607D3A110D for <dmarc@ietf.org>; Tue, 2 Feb 2021 11:42:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bluepopcorn.net; s=supersize; h=Content-Transfer-Encoding:Content-Type: MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=7+MKsRFtF8bQx6jUJRVzjZ5U+XYpBgEkdxwuqGeHkoU=; b=P02cQEwe07prK5n3AXl5Xqv/qG vg9OGaO9T8/Apg0+L6HrgS7pxCOonrAsRfXveEh4EWKSXGGWHP3pNcvuoMdiFMNG6DMfpIsDT+27p M3W5U7rKq0v42C3R5IyNQTbL+XGZuYT8j9TvKDx7RA0F4hyzaIXj4OXrpAFdFl6qamH4=;
Received: from [2601:647:4400:1261:589f:60c4:bcd4:9d97] (helo=[10.10.20.144]) by v2.bluepopcorn.net with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <fenton@bluepopcorn.net>) id 1l71Ym-0006sE-0J; Tue, 02 Feb 2021 11:42:00 -0800
From: Jim Fenton <fenton@bluepopcorn.net>
To: John R Levine <johnl@taugh.com>
Cc: Alessandro Vesely <vesely@tana.it>, dmarc@ietf.org
Date: Tue, 02 Feb 2021 11:41:59 -0800
X-Mailer: MailMate (1.13.2r5673)
Message-ID: <4A21A4F6-4021-4C38-A707-0141593A3849@bluepopcorn.net>
In-Reply-To: <18d01d3d-9a22-fe33-fa36-8f3a92cce4@taugh.com>
References: <20210202174909.517906D2C88B@ary.qy> <286b8e6c-67b4-2c16-1632-16bf8cd95b78@tana.it> <18d01d3d-9a22-fe33-fa36-8f3a92cce4@taugh.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/8--4uSquZcb-PhIc8r7wzHQlM14>
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: Tue, 02 Feb 2021 19:42:07 -0000


On 2 Feb 2021, at 11:13, John R Levine wrote:

>> An SPF library implements the check_host() function.  It's up to the 
>> client to call it multiple times.  Is that client DMARC-aware?  As 
>> you may have guessed, my question is intended to understand how does 
>> a DMARC implementation actually ascertain whether an "spf=pass 
>> helo=smtp.example.com" is enough to validate "From: 
>> user@example.com".
>
> I use the opendmarc library and libspf2.  For the SPF check, I give it 
> the IP address, the HELO, and the MAIL FROM, and it gives me a result. 
>  I then pass that result to the DMARC library along with the DKIM 
> results. Looking at the code, I see I tell it whether SPF checked HELO 
> or MAIL FROM by simply checking whether MAIL FROM was null, but I 
> don't know what the DMARC libary does with that.  Maybe Murray 
> remembers.
>
> There is some commented out code to not pass a HELO result to DMARC, 
> don't remember why I turned it off.

I’m lost in a double negative here: did you turn off passing a HELO 
result to DMARC, or did you turn off not passing a HELO result?

> Again, I believe this is typical of what DMARC validators do.  It's 
> existing practice and I see no reason to change it.  Can we stop now?

If you found that you needed to turn off something that’s part of the 
DMARC spec, it would be good to understand why.

-Jim