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

Douglas Foster <dougfoster.emailstandards@gmail.com> Tue, 02 February 2021 00:11 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 0FDB13A15DC for <dmarc@ietfa.amsl.com>; Mon, 1 Feb 2021 16:11:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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] 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 huoZ4qfsoJRo for <dmarc@ietfa.amsl.com>; Mon, 1 Feb 2021 16:11:35 -0800 (PST)
Received: from mail-vs1-xe32.google.com (mail-vs1-xe32.google.com [IPv6:2607:f8b0:4864:20::e32]) (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 677223A15D9 for <dmarc@ietf.org>; Mon, 1 Feb 2021 16:11:35 -0800 (PST)
Received: by mail-vs1-xe32.google.com with SMTP id i12so7189394vsq.6 for <dmarc@ietf.org>; Mon, 01 Feb 2021 16:11:35 -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 :cc; bh=fyUSrOsoN2SVodiThoN1KtDvbTQbXAV51f0Y82eKv4A=; b=J2oEMsOuUkRF0GlqH91vL35jgeuFdWWs9dTXfUBGrtnZRW/Kalv8HsRte++A+2mCde usmbOkkOPaC6suNv66HGR895SbTGrGfSW2liNtamjWlC24hrF9V781wR6i8WPocd6wih wJdphP6W5ZtCtjA8sATCvq3WKc/rRuHRl8bXMyB7cI8hCOsTGfmgZGSdXR2NpFRQmPKN 9iIpqbxV1X9/ycVr6v8SPuKKRhWRBbjM+tCwXYevsgu++piZZggdFvVXrK46D2NZBtAE pfrR8p2az2QmlRlYeirxWrTi8pSHGFk0wje/cCXnExU/FYS0KGwdHTSbKrDR9y73HJ9g CaGQ==
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:cc; bh=fyUSrOsoN2SVodiThoN1KtDvbTQbXAV51f0Y82eKv4A=; b=mS2HmsDkLbbKAuhfq9LrzwyWm46tijsnmyjpDTHMMzxXo/jY5UZqo9tL3vuHKPxLl8 cTnhgN09JFLh8TWPQfdQYO7WpFLyN472xrCd6C8Qpqxlcdh7Nj+66uX/8d1mSq1PzF7W zj4wfXmq+hY8sB82yD6tdRA7nSkCoB6/BvNZMIwG8EkDRyViLY6hR+zNJaSp+2W2XNVD Qrf2lbE8KLpRd+WsF8dEQF+Ax50vIy7euSyYycRA4T9GS2i6EVuSTt2UgwrpNiWIffCd Qe0dFSQNQtFx02K3pQXyWWAKWfXm4TINLoFP054bXZRrE2qiGasiz9cDMRRaaZQUXtiz 73uQ==
X-Gm-Message-State: AOAM533GM+Vpf9S177YKTRBuLbTk+Bdfres34u23ecs0cesn9aN5SSxG j+/KJ0h04EsNdIcu82cYpYS58iLQRMVldSMSti0=
X-Google-Smtp-Source: ABdhPJz8SiOHohzmZIvi0+xYxR4GvEkPXtp/bfRr4xTAniAj1X2laH6ZyuH3GEF1hh4meIXTKpfxJI8qCW4Tgqxl27Y=
X-Received: by 2002:a67:c29e:: with SMTP id k30mr11049420vsj.45.1612224694321; Mon, 01 Feb 2021 16:11:34 -0800 (PST)
MIME-Version: 1.0
References: <20210130212339.447316D04763@ary.qy> <1654196.ygyh55z74P@zini-1880> <babf1538-5172-f101-d5e4-c4fa33dea495@tana.it> <4489192.U1a6Vm75Xl@zini-1880>
In-Reply-To: <4489192.U1a6Vm75Xl@zini-1880>
From: Douglas Foster <dougfoster.emailstandards@gmail.com>
Date: Mon, 1 Feb 2021 19:11:22 -0500
Message-ID: <CAH48ZfxB8OoA=3YCdj9mCf3sBzRo8Cu0Tg0z70_tCqQ6QmsCTg@mail.gmail.com>
To: Scott Kitterman <sklist@kitterman.com>
Cc: IETF DMARC WG <dmarc@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000034045505ba4f50d0"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/xTXgDCoXMA4bx8L8ONMuqEZ92M4>
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 00:11:37 -0000

I think I finally understand the complexities of this issue.   SPF is two
different validations, largely unrelated.

Test One:
A connection comes in and a server asserts a HELO name.   Before
proceeding, the recipient was to check if the HELO name is plausible or
fraudulent.    One way to do this would be to forward-confirm the HELO DNS
name to the source IP.  An alternate method is to use SPF to see if the SPF
policy says that the HELO domain can send from the Source IP.   I do not
understand why the domain owner would be able to configure the SPF policy
but not the host name in DNS.   Perhaps for organizations with 1000s of
servers, creating a DNS entry for each machine seemed onerous.   In
practice, the large organizations do have DNS entries for each server, and
they encourage others to do the same.

A recipient who gets a FAIL result from this HELO test could decide to
reject the connection without ever proceeding to MAILFROM.  This is why the
specification suggests testing HELO before MAILFROM.   We know that
internal host names, such as "mail.example.local", will fail both of these
tests because the local domain cannot be published in DNS.   I expect that
any attempt to require a PASS from this test will encounter an unacceptable
number of false positives, so I do not see it as particularly useful.
But the option exists.

Test Two:
If the conversation proceeds past HELO to MAILFROM, then the second
validation is performed:   Is the Source IP is authorized to send on behalf
of the SMTP domain?   When the SMTP address is null, then
postmaster@HeloDomain serves as a proxy for performing this test.

We have two different tests, and two paths for performing the second test.
 Organizations have the choice of whether to implement one, both, or
neither test.   But the two tests are complementary, not mutually exclusive.

HELO test violations will have nothing to do with message flow path, since
the test only examines whether the adjacent server name can be plausibly
linked to the adjacent IP address.  A DKIM signature is not a third way of
answering this question, because a DKIM signature cannot be reliably
associated with the server that applied the signature.   Nor do I think we
want a third solution to this question.  Consequently, the HEL:O test is
unrelated to DMARC.  The SMTP Address test is appropriate to DMARC, whether
it is evaluated using a supplied name or a derived name based on
postmaster@helodomain.

DF