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

Douglas Foster <> Wed, 03 February 2021 11:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AA3CC3A08F4 for <>; Wed, 3 Feb 2021 03:51:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Status: No, score=-2.096 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, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id UUUfkUXsTIKg for <>; Wed, 3 Feb 2021 03:51:35 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::a30]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B64203A08ED for <>; Wed, 3 Feb 2021 03:51:35 -0800 (PST)
Received: by with SMTP id e1so5559911vkd.10 for <>; Wed, 03 Feb 2021 03:51:35 -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=4huM2KkJJ4GujD7r7SSyqlXTrE14Q0rWkWYqHKARxkg=; b=hRX3FnoQjvh6AQLCWpK9/+zp0I3Ybm0gHlB02NoJML75c5IWVQPJ1ARnVUtzJLEXRH 6BL1erllFRDiCiUnMO0y3H/0mWzVRQdqKSRdnIhuXpadxuegEDWpdkeZdbEzqY6HWRWV Rk7QCcsYdJAPzuNriqHFZc3Gc1fi+Lozu1TIKeWAOcrFqXYwMGspsFSEk8PgLuFBj8Jb smW97OVPEfoR2FOOZMAh7/eDvT4xNnT/pPhstuOLXigc3TglJu63I0FKuu++610mLi+u ofAC8YfoZNmkNHSpxZdE0eE6mxWw4cGvRdhEJ6OS8B3FSsbXFIdISlu4+sdkkYWZ9Q2u XJqQ==
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=4huM2KkJJ4GujD7r7SSyqlXTrE14Q0rWkWYqHKARxkg=; b=HwS2jBq9lEb0PB7mKGkSsm8zVCr0gfZrJhJ3topN49Exf8gEM+QHDGR5Dy49K5h/G0 TSNRakX5MNOjeNNpIE16YBzq/CUpQiHAr/Zx/QgJu0L7I/OqL+6gt5ir98obDhT7iQ4Q GkY/BoQiUe2kyMMskFojxXNKHQ1cagWtVHv/WnfDUa2av4Zd8tg7VhqIkrZerVRRT2s2 EbPUBwUGiXqbmeSrWxcy7tCQFrnHK+fSizVFNtFfFpEULxUU+I1s63u46AWbY9Up2MKc x0wfUQxJ6BVbRyez01LuXFz7ayiou+VcvfJPfoUityvcXAXd1MKR706HGSDGDGWA8kBs F4KA==
X-Gm-Message-State: AOAM533wg3AV61nnxW+Aiyhs6+MHWNvCPeL6yoSl5dXxRYymLbGuh5GQ m8GPSskoZRf4WrH8GtMA620ZLEhYu7m5XxW07L/cbHyCfwA=
X-Google-Smtp-Source: ABdhPJxGcD0aW6N0fVpWZd2Iz8mcK9IDDeT+1ccZ9Kh/CMiZXxEGPtghsRwsd+gmKMpRatNrBi7EdaMvjz34WTC2mr8=
X-Received: by 2002:a1f:3112:: with SMTP id x18mr1259038vkx.4.1612353094541; Wed, 03 Feb 2021 03:51:34 -0800 (PST)
MIME-Version: 1.0
References: <20210202174909.517906D2C88B@ary.qy> <> <> <> <>
In-Reply-To: <>
From: Douglas Foster <>
Date: Wed, 3 Feb 2021 06:51:22 -0500
Message-ID: <>
Content-Type: multipart/alternative; boundary="00000000000073e56005ba6d3579"
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: Wed, 03 Feb 2021 11:51:38 -0000

I believe that most code is validating the MailFrom parameter if it is
supplied, and validating the HELO name only if MAILFROM is null.   This is
based mostly on the way SPF has been discussed over the last 15 years,
coupled with the observed behavior of a limited number of
product implementations..

If we are to argue that HELO and MAILFROM tests are interchangeable, we
have to deal with the situation where the domains are different and the
results are different.    SPF has 7 possible results, so there are 49
possible combinations of these two tests, 42 of which are divergent.   (If
we factor in NXDOMAIN as a separate result, which even RFC 7208 says is
probably appropriate for HELO, the number of divergent results is even

To merge the tests, we would need to define a winning result for all of the
divergent result pairs, and then demonstrate that our winning result can be
considered appropriate for all installations.   Such an undertaking has not
been attempted, and I cannot imagine it achieving consensus.

The result needed for DMARC is the result I believe is actually being
produced by most installations:   The result is evaluated based on MAILFROM
when it is not null, and evaluated using HELO domain when MAILFROM is
null.   Of course, using HELO as a proxy for MAILFROM only works for bounce
messages being returned from installations hosting a single mail domain on
a matching host domain.   For everyone else, DMARC will only verify
automatic messages that are signed with the From address domain.  The DMARC
specification should make this clear to the reader.

- - -

To correct an earlier comment of mine:

fcDNS on HELO and SPF HELO tests can be used together quite effectively.
 fcDNS validates that the server is reporting a valid host name, limits the
allowed results to a single DNS domain, and demonstrates that the domain
being used for SPF HELO is the correct one.  However, fcDNS does not
demonstrate that the server is authorized to send mail.   SPF defines the
servers which are allowed to send mail for the domain, but may include IP
addresses from other domains, either directly or through Include clauses.
 When the host name is verified with both fcDNS and SPF HELO, the evaluator
knows that the server is in the reported domain and authorized by that
domain to send mail.

Note that this is also different from fcDNS on the Reverse DNS name, as
reported with the "iprev" test result.  We really do not have a way to
report test results for the HELO name.  It would seem desireable to add
test result indicators for both fcDNS HELO and fcDNS SPF.

Doug Foster


On Tue, Feb 2, 2021 at 2:54 PM John R Levine <> wrote:

> >> There is some commented out code to not pass a HELO result to DMARC,
> don't
> >> remember why I turned it off.
> >
> > I’m lost in a double negative here: did you turn off passing a HELO
> result to
> > DMARC, or did you turn off not passing a HELO result?
> The live code uses whichever result it has.  The commented out code only
> used a MAIL FROM result.
> >> Again, I believe this is typical of what DMARC validators do.  It's
> >> existing practice and I see no reason to change it.  Can we stop now?
> >
> > If you found that you needed to turn off something that’s part of the
> > spec, it would be good to understand why.
> I believe that what I am doing matches the spec.
> Regards,
> John Levine,, Taughannock Networks, Trumansburg NY
> Please consider the environment before reading this e-mail.
> _______________________________________________
> dmarc mailing list