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

Douglas Foster <> Thu, 11 February 2021 11:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0C8913A14E0 for <>; Thu, 11 Feb 2021 03:36:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.097
X-Spam-Status: No, score=-1.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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id k4W2zNpRYSni for <>; Thu, 11 Feb 2021 03:36:01 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::a2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9E7A33A14DF for <>; Thu, 11 Feb 2021 03:36:01 -0800 (PST)
Received: by with SMTP id k1so1200766vkb.11 for <>; Thu, 11 Feb 2021 03:36:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=lnQo7wc36xcCDf1V6Vcuoy+hMqFW58H44xoJDZziuNg=; b=ggi7LLLBS7g2McDyGdi+gfNws3kiHCkhA8VlBLG7OnZ77+2Hdm8/l2q3zb4j9bF9N9 ouoF8wRzfxaoHtDBFM7O1sJETvxknWi9ui6yAXwhlN5OioAsR6QzMXyFDF2B9JLuEksM 6b5DKJRVyiuzEvqo0U9p2w7o1YtcOgAuOy6VkBGPmMT6i2xfty8bKT5+uaFNt75Mol2u Wi5m3ueeOE3cWhyPE5fWH4MiwTIOz4UeVK/2pZ/92a6+HahzREv7dZOeoUkOCWFBvket z5MJX7DJNnQ7Ha0LMLHB31fKn7CBQX5hFIxjwPzQhHWH2o+mPS8sFyT7BwTz13jFziQC 2f9Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=lnQo7wc36xcCDf1V6Vcuoy+hMqFW58H44xoJDZziuNg=; b=B/W8I6a92WOVkKAfyQ01/PZovHr94KiFWXWVbewLqcLV7AH2PATXFaxo1cwLc2k48K 9tkcxpm+nGLMUrLLP77WJN9aPHhJ7owj1ALUAxgp4Qmh6djj4Cuoz0sRbe3ePfHlaOb5 eLpqpWhLrfD7NM7EjQtAMPxM5h0jBOivOKl79+dAWPmp7lMwYvSBDjUqhz+WFMC6sMmT rpPpliIz8Twag+NjbMIA90qdnc8oCLOr9yzVun9Xdhh4JJ81dHTjXOmuAt9cpbmu5OC2 vEoia8qnia1Cm/SJM1yswCuU9Nt95cZk74AuWaTWdtjBl9xyJJ3/34HhA7k0GKVnnueF XnPA==
X-Gm-Message-State: AOAM531gJR0uQ2GWOoG1yZDc5sL1sjzAgQWPUQY6am73ngLYqxrHafsE uZS51k6VjKElPPh3Vj6iMaOo69wdl4Iy4Wd+RKMOPXzozcV80Q==
X-Google-Smtp-Source: ABdhPJzLEWyUgahruEIJb2yj3FNh6Bghgjf1+9fVSBjzz31yytowxHHoTifWtem4dhDpuCsIxDx1A3kyaffVvVVXwFE=
X-Received: by 2002:a1f:4c45:: with SMTP id z66mr4523963vka.4.1613043359363; Thu, 11 Feb 2021 03:35:59 -0800 (PST)
MIME-Version: 1.0
References: <20210203181226.9AB746D51182@ary.qy> <> <> <2285569.RditZUVBbg@zini-1880> <> <2244314.3GJdnAqG3q@zini-1880> <> <>
In-Reply-To: <>
From: Douglas Foster <>
Date: Thu, 11 Feb 2021 06:35:49 -0500
Message-ID: <>
Content-Type: multipart/alternative; boundary="00000000000071347405bb0decb9"
Archived-At: <>
Subject: Re: [dmarc-ietf] Ticket #1 - SPF alignment
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 11 Feb 2021 11:36:03 -0000

Applying SPF to DMARC could become out of scope, if we choose to remove SPF
from DMARC and make it dependent only on DKIM.   Until then, we need to
have a shared understanding of how SPF is applied.  This question asks
whether that shared understanding exists.

SPF involves two tests, which can be used together.   This WG can insist
that for DMARC purposes, only one can be used:

    "When the sender is not null, DMARC-evaluation only considers the SPF
evaluation of the MAILFROM Address.   SPF evaluation of HELO MUST NOT be
considered for DMARC purposes."

This wording seems implied by the current language, and by those who want
to leave it untouched.  Implication is different from specification, so our
document should make this explicit.   Unfortunately, an explicit MUST NOT
requirement is hard to justify.   When two domains are involved, and both
domains have published policy information, what justification exists for
ignoring some of the available security-related information?

If we back away from MUST NOT, then we have to consider that some
recipients MAY evaluate SPF HELO and SPF MAILFROM together, just as the SPF
RFC expected them to be used, and as outlined in one of my examples.    If
some recipients MAY evaluate HELO, then senders SHOULD take care to ensure
that HELO will generate a PASS.   Our language becomes something like this:

    "When the sender is not null, DMARC-evaluation always uses the SPF
evaluation of the MAILFROM Address.   Some recipients may evaluate SPF HELO
as well.   To maximize recipient trust, senders SHOULD publish an SPF
policy which ensures that both MAILFROM and HELO will produce SPF PASS


On Wed, Feb 10, 2021 at 6:29 PM Dave Crocker <> wrote:

> On 2/10/2021 3:24 PM, Douglas Foster wrote:
> > Huh?  Are you asserting that SPF MAILFROM and SPF HELO are
> > interchangeable?   They are not, but they can work together.
> Perhaps I misread, but I thought I saw that this really is out of scope
> for this working group.
> d/
> --
> Dave Crocker
> 408.329.0791
> Volunteer, Silicon Valley Chapter
> American Red Cross