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

Douglas Foster <dougfoster.emailstandards@gmail.com> Tue, 01 December 2020 23:20 UTC

Return-Path: <dougfoster.emailstandards@gmail.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 A4DE13A0B16 for <dmarc@ietfa.amsl.com>; Tue, 1 Dec 2020 15:20:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 (2048-bit key) header.d=gmail.com
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 IJEcwsvfHLfM for <dmarc@ietfa.amsl.com>; Tue, 1 Dec 2020 15:20:23 -0800 (PST)
Received: from mail-vs1-xe2e.google.com (mail-vs1-xe2e.google.com [IPv6:2607:f8b0:4864:20::e2e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 979B33A0B15 for <dmarc@ietf.org>; Tue, 1 Dec 2020 15:20:23 -0800 (PST)
Received: by mail-vs1-xe2e.google.com with SMTP id x4so1894789vsp.7 for <dmarc@ietf.org>; Tue, 01 Dec 2020 15:20:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=Ksd80fPGhPtRwHohFvvdSV497er0Ivd0N3qwDXwYH2E=; b=HfbfOIVKIa3TncjXqdLbIGaJ/ilONNIFRRmQpSfLwkIsdez9F77mlzsyHXvhO/uDA4 cm1zs5f8i7EZ82OerhWzxRs6IWUozAQyqnBWitwJe/V5PaTnzeRBuDu6GFdgR7wqqd6W 2Lfa40EGQNflsaVtftabLUlth17k7K5Nq6F0PyNk4GuyhNsK3bH7ctDy8sxFgblsz7in zYd5jZjyyzkZQyychjwqljv3CNugScthlB8Dyi0R4pDRi+TCyzzRb69vIIzWBstzStic BTv2pz/HW7mNDG4sK7iMQEBrs5rTo2ibbhIW8NUakoy/UbiuBwBT0Jelv9nj4spTerXO yOKg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=Ksd80fPGhPtRwHohFvvdSV497er0Ivd0N3qwDXwYH2E=; b=FAgbW8Cj9u+VZKmfZqrnaPReshYg9Panx5aXzbgwFS75CgceKGlSrUGDtU81JS8TXS 4JNyLOatqzJZnEtymYsCVbKU/gzR1oa22wfkXEVrb4W9273GjYSY8raettOYgTfwkPV9 r3T2z1C9O8plQoq3RqdneSk8xDgrnF/t/yFuSUHEpg6L1kaKACQW7l4l45d5y3Wqbpuc cP3/WAuRpKUBxlzcNY7XwlJ+bkvUeSBGYjBQkTP5R7JUMezI/aGmNw8M4jDhgikwTUJ0 6QEQB3vs38VeVoZ6Wv5dhigUWvDyy5yBgggwSujxpAJrxy0ZfmBYAgW6tJumA74V+SVN YVjg==
X-Gm-Message-State: AOAM53055Z/hqmy/RhL2WPkxpl141o8fDHoA8M4qiuBM+qSVGJcvXk+2 fe8aFzk2+SZgWUPo/jHBRHfcqaQlUW3uqfhoJd4gxo3M
X-Google-Smtp-Source: ABdhPJwjGKiHAHFjePs59+4WKPzbtzkui8A5hRaw8ejgETYLyjgit1+yZeNDZJ7Pks2JT6p2w3K2erSRE3FkKaNNdnI=
X-Received: by 2002:a67:fad2:: with SMTP id g18mr5261924vsq.45.1606864822592; Tue, 01 Dec 2020 15:20:22 -0800 (PST)
MIME-Version: 1.0
References: <bef64e7a-571b-a73f-dc91-aa402ca320c8@taugh.com>
In-Reply-To: <bef64e7a-571b-a73f-dc91-aa402ca320c8@taugh.com>
From: Douglas Foster <dougfoster.emailstandards@gmail.com>
Date: Tue, 1 Dec 2020 18:20:12 -0500
Message-ID: <CAH48ZfzkGFWjTbEp9P5FOt4OmqwQ49tOe_gzVuo97mLFcvA1QQ@mail.gmail.com>
To: dmarc@ietf.org
Content-Type: multipart/alternative; boundary="000000000000f3e5c905b56f5ec4"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/CMII-UvOykZYlojp5V7S_zaYKM4>
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, 01 Dec 2020 23:20:26 -0000

1) ACCEPTABLE:   Server Domain matches RFC 5322 From domain, and RFC 5321
Mail From is missing.
HELO is an appropriate proxy for the missing Mail From, especially since a
missing Mail From implies a system message, such as a server might need to
generate.

2) NOT ACCEPTABLE:   Server Domain matches RFC 5322 From domain, but RFC
5321 Mail From is a different domain.
All this tells us is that the Mail From domain is a client on that system.
 Being a client of a hosting service does not give the right to speak for
the hosting service.

Doug Foster


On Tue, Dec 1, 2020 at 5:17 PM John R Levine <johnl@taugh.com> wrote:

> We would like to close this ticket by Dec 15, two weeks from now, so short
> trenchant comments are welcome.
>
> Ticket #1 is about SPF alignment.  We need to replace references to 4408
> with 7408, ando clarify what if anything we do with SPF HELO checks if
> the MAIL FROM is null.  One possibility is to say only MAIL FROM SPF
> counts, if you want to align your bounces, sign them.  The other is to
> explicitly say that HELO alignment is OK on bounces.
>
> R's,
> John
>
> ================================================================
>
> From: Anne Bennett <anne@…>
> Date: Fri, 16 Jan 2015 19:10:56 -0500
> Subject: [dmarc-ietf] SPF RFC 4408 vs 7208
>
> On Jan 6, Murray S. Kucherawy confirmed fixing the reference for
> the SPF RFC from the now-obsolete 4408 to 7208 ("Fixed in -11").
> However, -12 still has, in section "3.1. Identifier Alignment":
> For example, [DKIM] authenticates the domain that affixed a
> signature to the message, while [SPF] authenticates either
> the domain that appears in the RFC5321.MailFrom? portion of
> [SMTP] or the RFC5321.EHLO/HELO domain if the RFC5321.MailFrom?
> is null (in the case of Delivery Status Notifications).
> Actually, RFC 7208 states that:
> Checking "HELO" before "MAIL FROM" is the RECOMMENDED sequence
> if both are checked.
>
> ... and implies that if the first check passes, the second
> is unnecessary:
>
> If a conclusive determination about the message can be made
> based on a check of "HELO", then the use of DNS resources to
> process the typically more complex "MAIL FROM" can be avoided.
> So the RFC5321.EHLO/HELO domain is checked not only if the
> RFC5321.MailFrom? is null - in fact in cases where sites have
> followed the RFC 7208 recommendation, it will be checked first,
> at least by a "pure SPF" implementation.
> This means, first of all, that the -12 text above needs fixing.
> But also, I'm struggling with what it means for alignment.
> I can think of some real-life cases where only one of
> HELO or MAIL FROM aligns with RFC5322.From, even though
> both would "pass" in a pure SPF check. IMHO, Section
> "3.1.2. SPF-authenticated Identifiers" needs to be clarified
> to better take HELO into account.
> I'd like to see an approach similar to that for DKIM, where it
> is explicitly stated that:
> a single email can contain multiple DKIM signatures, and it
> is considered to be a DMARC "pass" if any DKIM signature is
> aligned and verifies.
> Similarly, I think that for SPF, it should be considered a pass
> if either the MAIL FROM or the HELO is aligned and results in a
> pass at the SPF level.
> But whether it is decided to take into account both HELO and MAIL
> FROM, or whether it is decided to ignore HELO (modulo its use to
> construct an artificial MAIL FROM if the latter is null), the text
> should IMHO make this clear one way or another, both in "3.1.2.
> SPF-authenticated Identifiers":
> 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.
>
> ... and in "4.1. Authentication Mechanisms":
>
> o [SPF], which authenticates the domain found in an
> [SMTP] MAIL command when it is the authorized domain.
> In both cases, the text should specifically mention HELO,
> and whether to include or exclude a HELO SPF result, in view
> of HELO's prominence in RFC 7208.
> If it is decided to allow both HELO and MAIL FROM results to be
> passed back to DMARC, then in section "6.6.2. Determine Handling
> Policy", item 4 should be updated to reflect that as
> well._______________________________________________
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>