IETF Logo Mail Archive

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

Alessandro Vesely <vesely@tana.it> Thu, 04 February 2021 12:50 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 2F13D3A1405 for <dmarc@ietfa.amsl.com>; Thu, 4 Feb 2021 04:50:29 -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 YZyNBTyeq8Wo for <dmarc@ietfa.amsl.com>; Thu, 4 Feb 2021 04:50:27 -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 4E7E73A1403 for <dmarc@ietf.org>; Thu, 4 Feb 2021 04:50:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1612443024; bh=XESHsBhWGdM5o8R+E1RJD+OCgxb6GKyUZppeIB88ElI=; l=1228; h=To:References:From:Date:In-Reply-To; b=ABCNdXWpwDrqyou2lqH2NdlvWa/tedpByW/m7wKEYBdecAmNn4Sa+MmUm5X1J7GAn lbPL+33Rv+68cfdVxft7CE8MKlL6LTU04Fl9qRIgh8LxjRsKbr0Od1A5YfS95VvhSe Z+WeAsexR0DNxSkkyV3KMoVkjAQIQqBTbydJK7u9iDEIM+EARoqGPx6EkZUjk
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 00000000005DC0C0.00000000601BED8F.00006311; Thu, 04 Feb 2021 13:50:23 +0100
To: John Levine <johnl@taugh.com>, dmarc@ietf.org
References: <20210203181226.9AB746D51182@ary.qy>
From: Alessandro Vesely <vesely@tana.it>
Message-ID: <e169f069-376d-7072-2538-c77bbe7b7540@tana.it>
Date: Thu, 04 Feb 2021 13:50:22 +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: <20210203181226.9AB746D51182@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/Ks6ZMEOuGQ-KvBCuCHNpcKiC7jQ>
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: Thu, 04 Feb 2021 12:50:29 -0000

On Wed 03/Feb/2021 19:12:26 +0100 John Levine wrote:
> In article <b396cf21-05f4-a1a4-5abc-78c5aa276473@tana.it> you write:
>>On Tue 02/Feb/2021 20:13:42 +0100 John R Levine wrote:
>>> It's existing practice and I see no reason to change it.
>>
>>Software changes all the time.  If we change, ...
> 
> Urrgh. There are still MTAs that haven't been updated from RFC 821. If
> you want a real standard, the closer you can make it to what the
> running code does, the most likely it will work.


How about this:

     NOTE: Historically, SPF was focused on the mfrom identifier.  The helo
     identifier was retrofitted later, in order to account for delivery status
     notifications.  Earlier DMARC specifications followed suit.  Subsequently,
     it turned out that SPF records for the helo identifier are actually sharper
     than those for mfrom, thereby making successful helo verifications very
     reliable.  However, in the vast majority of cases the mfrom identifier is
     aligned with the main DMARC identifier, while the helo identifier often
     does not have a corresponding SPF record.  Therefore, the common practice
     of using just the SPF result of mfrom unless empty is still a valid
     heuristic.

?


Best
Ale
--

v2.23.0 | Report a Bug | By Email