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

"Murray S. Kucherawy" <> Wed, 27 January 2021 20:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5A9233A0EB5 for <>; Wed, 27 Jan 2021 12:10:51 -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 ags2y8xQ2MUY for <>; Wed, 27 Jan 2021 12:10:50 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::a35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CEFAD3A0EB2 for <>; Wed, 27 Jan 2021 12:10:49 -0800 (PST)
Received: by with SMTP id m25so810905vkk.6 for <>; Wed, 27 Jan 2021 12:10:49 -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 :cc; bh=/SL8q2dwvbYeVuTEnBKl6DpDMvlUzzgP15YR7GVxGo8=; b=jv34vQTflOBLP24E+ZJ0tSLDRUnR48HfbnCgTTP7HIuDlzvOWMT23snVbORdWTbDfJ n82ALJEGpN8/S730nGFdSPJd0uGPTA/aBB2K7/b65Rv5hKkr67uFZLKjzBMRud2WqPQf nPst+XbenqkULqbQKmGDZlVgadUsoD9hNzc3prrygtl6SEqsNcnG80m2MV9px5wZMv90 X/EzNeUZkV/BL1SQxSf1MXJ4MBqpiAgqAW/qs+HjemguWSBPcIYfrkmuCj+8H5iF5zwv Fkxh3jbom/es0GXZYeZF8kyoExgotdrTFr1ktfPSwQu6LoRYPnGM2XmsFC+rsIDIf3t3 PhMQ==
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:cc; bh=/SL8q2dwvbYeVuTEnBKl6DpDMvlUzzgP15YR7GVxGo8=; b=o6UizGVYOn+ENhrp/Il6B8aU2Th7iishTgVDSlQvndj2gZH4gFcamlvlhvIzDnDW5U ODxNtZoX/D5okYMQehf/x8tt0MCsV8GrMF/+LgKbStkGK1Cl2c/m/umEDNtVrtvT62GS cY9nHJu3AdMgAmZpF3J00wCufz4AE/qF5Skqf9/phvTaOqL3RzPgiPdpnxMWqRVOY/pD blEH6ws/jugOtVrwUVm0+Ejj3IyXHTz8r6UbRx/aS3tFjmyaZW3jTkCw3/jwAccMjH2R Fhm3wXBEs3b8xO4DmStodD5huYF+Ofa9clnJYm5aMXSqogospXZQJBzTTpx5uORD9z0t 4Oag==
X-Gm-Message-State: AOAM532eQBntIJ3mdlpfzKQ2Ip7NJcAT+ChEnKMKg09brOu8jm08sxBg osg3uwV4yLXKUJd+2GozTr7xlFpCQm7r/fABBw8=
X-Google-Smtp-Source: ABdhPJz8Z75pOmvnc+HE3jwCO4IJ6GjyNM3AFIn4Z/6368bPjAsC0zmWoA6AAfl7ihUTGxfZslKR1RycN4fAmZhvTzg=
X-Received: by 2002:a1f:30cd:: with SMTP id w196mr9571428vkw.13.1611778248344; Wed, 27 Jan 2021 12:10:48 -0800 (PST)
MIME-Version: 1.0
References: <> <1655426.E2olI3CrJK@zini-1880> <> <3776619.NdRDDhGtae@zini-1880> <>
In-Reply-To: <>
From: "Murray S. Kucherawy" <>
Date: Wed, 27 Jan 2021 12:10:37 -0800
Message-ID: <>
To: Alessandro Vesely <>
Content-Type: multipart/alternative; boundary="000000000000f3098205b9e75d65"
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, 27 Jan 2021 20:10:51 -0000

On Wed, Jan 27, 2021 at 9:26 AM Alessandro Vesely <> wrote:

> AFAIUI, there's no reason why SPF would work with a logic substantially
> different than DKIM's.  DKIM can provide n identifiers, if one of them is
> aligned and "pass", then DMARC is "pass".  SPF can provide 2 identifiers
> but
> one of them is of class B.  WTF?

DKIM (in its simplest form) returns N tuples of the form (d= domain,
pass/fail).  All of them were run through exactly the same check; all of
them were attached to the message in exactly the same way; all of them have
essentially identical semantics.  Giving them equal footing makes sense to

The two identifiers in SPF hold different places in the SMTP session, and
have different semantics.  I think treating them differently is also just

Can anyone explain why we have a <scope>helo</scope> element in aggregate
> reports?

Not off the top of my head.  If it's not meaningful, it should go.

In addition, as I said, SPF filters are likely to report HELO as helo and
> FROM as mailfrom.  If we want to carry over this quirk, the spec must say
> that
> a DMARC filter which gathers SPF authentication status from an upstream
> filter
> MUST make sure that mailfrom is empty before validating based on an
> aligned helo.

...or it doesn't evaluate against SPF at all in such a situation.

Dropping that absurd discrimination between SPF identifiers would make for
> a
> smoother spec.  Since non-null mailfroms are in most cases aligned with
> either
> From: or helo, the differences between existing compliant implementations
> and
> the smoother spec would be limited to a hardly noticeable set of test
> messages.

I don't think we should ignore what those two identifiers mean, how likely
they are to contain junk, how they are applied, outside of DMARC, etc.

-MSK, participating