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

Douglas Foster <> Sun, 31 January 2021 19:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 910013A11C3 for <>; Sun, 31 Jan 2021 11:03:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id DR4bYTvY6Ibr for <>; Sun, 31 Jan 2021 11:03:57 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::92f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BC5F43A11C2 for <>; Sun, 31 Jan 2021 11:03:57 -0800 (PST)
Received: by with SMTP id a16so5140702uad.9 for <>; Sun, 31 Jan 2021 11:03:57 -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=AV9vw3TKVsrOgtk20k7ZOxk3EcMehNKGuNbqSF8VIsU=; b=EpMmmC3MqRD2NVEE5UjRpdbRj2WgjlcfwXgnZM5MGy5AO69PH9qCplDK/G0aVLPxxo f0cB+a5AyHGrU4yWLA0+S8ow+ppN4ofuVZOA8Al8pOEr2/eV2iRBV867/20XbbYxmqjZ qAajqK40vp2Zz0UN0qsxoLhJmV6qrmsWVcXJawKIHXP9+elUtSrIj/qRArR/+2Srclj9 0M+I8qkJDDE616BUvnbfk116WmTxWRoZN6kx1JZfmsqXKCOj8VTjwjODYdGkhkJxeMO8 dvB1h+GuCzOcFlGz4NWyaGid9vMYwjhQ3IGz28Flu8miOgu7JqzWejrPQMwtMNrwFvBo O9wA==
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=AV9vw3TKVsrOgtk20k7ZOxk3EcMehNKGuNbqSF8VIsU=; b=f9AACp2jDVauZTAQBqJ1Vw39pbMb3dR6cOiqa2G36zW8Pc/T4onlKjoUMSCFR/tYdm /IHkv7/ndICiUXUesB+N/K3CvsWeURT9QHDzOUNERA3+G7MkhCK5/Vct2ctwQLXXS4XQ Hsy6YpHcjvBVKAfHzh13XMt3GhrstnApR5fZs53M5iPV8HiOefmSo5fLMpk2aiucZr5V bneItj0uCYSX1PLOY3G9qHLP+0UpJBy9TLeSSch3dRkqbdC/bVZ7aNAN8/sZ/Yx1sbAR CP51SLUXT/zBFjXJnr5tK8A7vnT7qg//LHZglkzTTETKPIc2B5+ojIVNBtt+FqsgQKzm JlDg==
X-Gm-Message-State: AOAM530awmbrNAJyagjnNiMVkoDogLeP2DC2f5g+fQTs0b3s2hZgS35i Iyfd4JaslIgO+r/qIhakOJn+5INTAXfqcWabl36T/zPvOYk=
X-Google-Smtp-Source: ABdhPJyAwYVKyA25vUyNK3M4U1h9BxcBDazJTJ/acYTZV840iKr1nCDq+XarRkaj3p4S3T4PInKW9PY+SwXOwbXf/I4=
X-Received: by 2002:ab0:7547:: with SMTP id k7mr7719081uaq.95.1612119836217; Sun, 31 Jan 2021 11:03:56 -0800 (PST)
MIME-Version: 1.0
References: <20210130212339.447316D04763@ary.qy> <> <> <> <>
In-Reply-To: <>
From: Douglas Foster <>
Date: Sun, 31 Jan 2021 14:03:45 -0500
Message-ID: <>
Content-Type: multipart/alternative; boundary="0000000000002c531b05ba36e615"
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: Sun, 31 Jan 2021 19:04:00 -0000

I don't see any justification for using HELO unless the SMTP address is
null.  If the SPF RFC says otherwise, this should be corrected.   Proving
that the server domain can be tied to the IP address does nothing to prove
that the SMTP address can be tied to the Source IP.

For DMARC, HELO is only useful if the message's From domain and the
server's HELO domain are aligned.  A high percentage of email domains use
servers from a different DNS domain, so this will only be true on an
exception basis..   Consequently, software products that apply DKIM
signatures to messages MUST be able to them to automatic messages as well.
 Once developers provide MTA and mailstore products which service the needs
of hosted domains, then users of non-hosted domains will be able to sign
their automatic messages as well.   Ergo, any supposed need for HELO with
DMARC will go away.


On Sun, Jan 31, 2021 at 11:52 AM John R Levine <> wrote:

> On Sun, 31 Jan 2021, Alessandro Vesely wrote:
> > One way to interpret RFC 7489 is that you can put dmarc=pass based on
> the
> > helo identity *only if* MAIL FROM is null.
> That would be consistent with 7489.
> Sec 3.1.2 says
>     Note that the RFC5321.HELO identity is not typically used in the
>     context of DMARC (except when required to "fake" an otherwise null
>     reverse-path), even though a "pure SPF" implementation according to
>     [SPF] would check that identifier.
> But then 4.1 says
>     o  [SPF], which can authenticate both the domain found in an [SMTP]
>        HELO/EHLO command (the HELO identity) and the domain found in an
>        SMTP MAIL command (the MAIL FROM identity).  DMARC uses the result
>        of SPF authentication of the MAIL FROM identity.  Section 2.4 of
>        [SPF] describes MAIL FROM processing for cases in which the MAIL
>        command has a null path.
> That section of 7208 says that if there's a null bounce address, SPF
> pretends that the MAIL FROM was postmaster@HELO.
> If we want, we can say not to use the SPF HELO identity, but that would be
> an incompatible change to 7489 and I suspect would not match what most
> DMARC checking code does.
> Regards,
> John Levine,, Taughannock Networks, Trumansburg NY
> Please consider the environment before reading this e-mail.
> _______________________________________________
> dmarc mailing list