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

Douglas Foster <dougfoster.emailstandards@gmail.com> Wed, 03 February 2021 00:30 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 031D33A10AD for <dmarc@ietfa.amsl.com>; Tue, 2 Feb 2021 16:30:38 -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 CeP_PpU6Zd6v for <dmarc@ietfa.amsl.com>; Tue, 2 Feb 2021 16:30:36 -0800 (PST)
Received: from mail-vs1-xe2b.google.com (mail-vs1-xe2b.google.com [IPv6:2607:f8b0:4864:20::e2b]) (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 400913A10AB for <dmarc@ietf.org>; Tue, 2 Feb 2021 16:30:36 -0800 (PST)
Received: by mail-vs1-xe2b.google.com with SMTP id b10so6111014vsa.8 for <dmarc@ietf.org>; Tue, 02 Feb 2021 16:30:36 -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=3blrH9Lx/RE+ug9CHDVFOev8r3zmd3xZlhiRvEbGLS0=; b=lLT+kwHeiFqiuwuqGPCcGhvvT1u3e2NLsoSCwQSJTBquW68wM6TVmEwX1a8s/is41/ XkYMjX7d1SQiKd3OdM1Em/bWmk1FQxaPYM2iODLbKFcYaGjVyK07JBepXyXwLEZAr3Yj JYgsmafM96wrTDlMZYn34b3XH79pE0tEr2up6Z1xq94A2MEaaKlH6IeBQ4Mcuev882TD nj1TXvXGGtjD/lmpssr7xpjOb5zIEvri2DflAc8J1bMU05U4BETHBCtFry7U2bF9AIjA B9w0XkXr7mAig6M+Umg8eEk5YeQRe+gGK4K3QvgKdtgpQyw6b+Rao8z5yq4kotLSOTmK jmLw==
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=3blrH9Lx/RE+ug9CHDVFOev8r3zmd3xZlhiRvEbGLS0=; b=pr/fXiBlYcEj33OWXgWh8NDKWxeDTqHxO7BBgIlUOL3FHzCeRrnUJHfb00sX29KuYM spIzFJxztDpaXL5Fj/l+EZ8gPXx19W+eCEblt1sed9GaXr/48cDE2CyHLa/BCy3+kG+g AOS0Zj7f91v9Du3uGW4H2b/IOUHhUTfowj2OAKIZYf152qZrpqLWXYmKMMGjNdjMmCW0 0CHx6xCQkU3SlxIB2FHUzbEy1kxLaGIiJ8Yaaysudt8HCrLRMo7TB/EKHcPL2XGGqlpB y8AviH85yNB/dnTzhgcrKvLY3OjDQB7tNRD8WzittL2jVZxkpAFC9hXF4B1cGXJnGI7V 4CXQ==
X-Gm-Message-State: AOAM532ef9CqT3EisPh3RrfoZiPkYFsXt+SRAV2ERgbqtgMOjECcW5qi wsKQUE0Y8h9bst7Ap1dnWYoe+OfDZxcgk7Dk+MWg7NJGxHOcJQ==
X-Google-Smtp-Source: ABdhPJzErOnDJMzO/11HAL/4CpITu7KTBSXEICTkPKnU56PVRbVEhGFnTe4tzcdsBSFOYqCODkn3/EhByQcTazHgPBs=
X-Received: by 2002:a67:c29e:: with SMTP id k30mr235570vsj.45.1612312235016; Tue, 02 Feb 2021 16:30:35 -0800 (PST)
MIME-Version: 1.0
References: <20210201231154.DAE426D208E1@ary.qy> <2e39680f-ed2d-fa38-daaa-7e0627cf0fc7@tana.it>
In-Reply-To: <2e39680f-ed2d-fa38-daaa-7e0627cf0fc7@tana.it>
From: Douglas Foster <dougfoster.emailstandards@gmail.com>
Date: Tue, 2 Feb 2021 19:30:23 -0500
Message-ID: <CAH48Zfxekq2ucYeOLTJT-fdoLNVWtnRaSi7C4p_eF_oZXEPMpw@mail.gmail.com>
To: IETF DMARC WG <dmarc@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000009051705ba63b2ab"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/PVJ1IR3I3xcaqVsAZSubg9bbjtg>
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 00:30:38 -0000

Yes, it is true that the spec says

    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.

However, it carefully avoids defining "definitive", which means the
interpretation of "definitive" is site-specific.   To my interpretation,
"definitive" means a local policy to whitelist or blacklist based
exclusively on the HELO parameters.   Such as decision will certainly allow
other operations to be omitted.

This interpretation is supported by the previous paragraph:

   It is RECOMMENDED that SPF verifiers not only check the "MAIL FROM"
   identity but also separately check the "HELO" identity by applying
   the check_host() function (Section 4
<https://tools.ietf.org/html/rfc7208#section-4>) to the "HELO"
identity as the
   <sender>.


and the subsequent paragraph:


     SPF verifiers MUST check the "MAIL FROM" identity if a "HELO" check

   either has not been performed or has not reached a definitive policy
   result by applying the check_host() function to the "MAIL FROM"
   identity as the <sender>.


We really have two different tests, which appear in the same document
because they exploit the same technology.


The limitations of Received-SPF become very conspicuous and problematic:

- The identifiers are only provided in comment text, which is optional
and has been omitted in the wild.

- Although comment text implementations appear to be standardized,
this is still less reliable than structured data.

- Even when the comment text can be parsed, only domain names are
provided, and the test type is not documented,

so there is no way to know whether the result is based on HELO or SMTP Address.

- Received-SPF needs to report two results for entities which perform
both tests, but multiple results simply create ambiguity..

- The Received-SPF cannot be linked to a specific Received entry.
The assumption is that it will only be used

 within a single ADMD, where the perimeter is known and all internal
MTAs are trusted.


We have integrated Received-SPF into A-R without improvement, and A-R
has been integrated into ARC without significant redesign.

Then we are hoping that a third-party organization will trust an ARC
which is based on this weak foundation.


DF


>