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

Alessandro Vesely <vesely@tana.it> Tue, 02 February 2021 18:17 UTC

Return-Path: <vesely@tana.it>
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 43BA83A0D3C for <dmarc@ietfa.amsl.com>; Tue, 2 Feb 2021 10:17:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.121
X-Spam-Level:
X-Spam-Status: No, score=-2.121 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=-0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1152-bit key) header.d=tana.it
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 ejQvtIq9w77q for <dmarc@ietfa.amsl.com>; Tue, 2 Feb 2021 10:17:42 -0800 (PST)
Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (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 46DAE3A0CD4 for <dmarc@ietf.org>; Tue, 2 Feb 2021 10:17:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1612289857; bh=IHNkPaBaEcRDS0xwKXnp7qkjfUk9uTf3LcvkhMR1ES8=; l=1678; h=To:References:From:Date:In-Reply-To; b=DOxi+DSwpMuEGMZ9beWnovzpGOtIgL4pWoR44QNUx7PujAyYGE7k0bap5+XQKDaiR OKYoNJ9mPdBLs6ByocYoPh232QIuN0GPCPGlhChB9gCQTePukT2xIgGHWUv9lH0IvH GIOcOnDV/NrXpflngoGdo+HB3LGxyW2lTPy/WEQBaAeo91gX8VvrH/Yabf+hr
Authentication-Results: tana.it; auth=pass (details omitted)
Original-From: Alessandro Vesely <vesely@tana.it>
Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.3, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC053.0000000060199740.00004825; Tue, 02 Feb 2021 19:17:36 +0100
To: John Levine <johnl@taugh.com>, dmarc@ietf.org
References: <20210202174909.517906D2C88B@ary.qy>
From: Alessandro Vesely <vesely@tana.it>
Message-ID: <286b8e6c-67b4-2c16-1632-16bf8cd95b78@tana.it>
Date: Tue, 2 Feb 2021 19:17:35 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0
MIME-Version: 1.0
In-Reply-To: <20210202174909.517906D2C88B@ary.qy>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/XhwdFqr70Zp6PMegxna-K9yZMj8>
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 18:17:44 -0000

On Tue 02/Feb/2021 18:49:08 +0100 John Levine wrote:
> In article <2e39680f-ed2d-fa38-daaa-7e0627cf0fc7@tana.it> you write:
>>> My MTA adds an SPF clause in the A-R header whether or not there's a null
>>> bounce address.
>>
>>How can it report, say, fail for helo and pass for mfrom in just one clause?
> 
> It doesn't.  It reports whatever the SPF library returns.
> 
> I'm fairly sure that every DMARC implementation uses an SPF library and uses
> whatever the SPF library returns, so I don't see the point of this argument.


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"quot;.


>>>> OTOH, properly implemented SPF verifiers could skip producing a Mail From 
>>>> result if the helo identity was verified successfully.
>>> 
>>> No, they could not.  That's not what the SPF spec says.
> 
> Sorry, that's not what the DMARC spec says.


My point is that the DMARC spec says something inconsistent, namely that SPF 
helo results are reliable but typically they are not.


> Once again, what problem are we solving here?  Can we stop now?


We can stop now and get back on it later.  That idiosyncrasy is going to stay 
there until we fix it.  I'd suggest to fix it by accepting an aligned helo pass 
unconditionally.  However, it can also be fixed by an explanation, as long as 
it is something more persuasive than "one can type anything at helo".


Best
Ale
--