IETF Logo Mail Archive

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

Alessandro Vesely <vesely@tana.it> Wed, 03 February 2021 17:43 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 5C78C3A0CB4 for <dmarc@ietfa.amsl.com>; Wed, 3 Feb 2021 09:43:59 -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 7P8zKHD83-K4 for <dmarc@ietfa.amsl.com>; Wed, 3 Feb 2021 09:43:57 -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 BDB263A0CB2 for <dmarc@ietf.org>; Wed, 3 Feb 2021 09:43:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1612374235; bh=ukE0xkixjCUOtQeEw+TyPXzLM35+/r6OwxkjOHKYZnI=; l=1944; h=To:References:From:Date:In-Reply-To; b=DYY0FJgNVb1hEtMaRDSdIIxhzb2bs7Ma//iBqlzj0vWtynzVPIRPJs82CVpFIfUXQ Zi/DD3GMPcj5ebYkOuC6klD5qxjHgC4bP/bSVFS1OgCj0t8PkZI9xAN6L3ApKfA/P8 qL44KE0B5KbVw5j+jzWpqV/zxayY0ZPFjQidA3INwJ6nFVE8Km+mSy/3oNiu0
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 00000000005DC083.00000000601AE0DB.00001C5B; Wed, 03 Feb 2021 18:43:55 +0100
To: John R Levine <johnl@taugh.com>, dmarc@ietf.org
References: <20210202174909.517906D2C88B@ary.qy> <286b8e6c-67b4-2c16-1632-16bf8cd95b78@tana.it> <18d01d3d-9a22-fe33-fa36-8f3a92cce4@taugh.com>
From: Alessandro Vesely <vesely@tana.it>
Message-ID: <b396cf21-05f4-a1a4-5abc-78c5aa276473@tana.it>
Date: Wed, 03 Feb 2021 18:43:54 +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: <18d01d3d-9a22-fe33-fa36-8f3a92cce4@taugh.com>
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/U-71xxLtdk7JQAX4r_5c-G1TvqI>
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, 03 Feb 2021 17:44:00 -0000

On Tue 02/Feb/2021 20:13:42 +0100 John R Levine wrote:
> 
> There is some commented out code to not pass a HELO result to DMARC, don't 
> remember why I turned it off.


Couldn't find the code you uncommented in.

Apparently, OpenDMARC reads Authentication-Results: (or Received-SPF:) and calls opendmarc_policy_store_spf() to save the result it parsed.  That way, the last value found is the one that will be used.

It seems that relies on upstream SPF filters writing a single SPF result.  If mfrom is given write its result, otherwise write helo's.  That behavior is presumably coded after DMARC's idiosyncrasy.  It would choke if applied to an unskewed SPF filter's results.


> Again, I believe this is typical of what DMARC validators do.


Yes.  Here's an example by Google.  You may note that the helo name reported in Received: must have resulted in an spf=pass, which is not reported:

ARC-Authentication-Results: i=1; mx.google.com;
        spf=neutral (google.com: 62.94.243.226 is neither permitted nor denied by best guess record for domain of user@fragolina.it) smtp.mailfrom=user@fragolina.it;
        dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=tana.it
Return-Path: <user@fragolina.it>
Received: from wmail.tana.it (wmail.tana.it. [62.94.243.226])
         by mx.google.com with ESMTP id d18si1599313edu.101.2021.02.03.08.37.32
         for <REDACTED@gmail.com>;
         Wed, 03 Feb 2021 08:38:57 -0800 (PST)


> It's existing practice and I see no reason to change it.


Software changes all the time.  If we change, this particular fix would probably be less noticeable than many other software bugs lurking amid the code.  Indeed, you have to craft a message on purpose in order to have mfrom fail while helo pass (as the example above).

We can even explicitly allow the existing behavior for historical reasons, if nobody recalls why the spec came out that way.

However, please, let's not write a quirky spec.

Best
Ale
--

v2.23.0 | Report a Bug | By Email