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

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

Return-Path: <superuser@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 5A9233A0EB5 for <dmarc@ietfa.amsl.com>; Wed, 27 Jan 2021 12:10:51 -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 ags2y8xQ2MUY for <dmarc@ietfa.amsl.com>; Wed, 27 Jan 2021 12:10:50 -0800 (PST)
Received: from mail-vk1-xa35.google.com (mail-vk1-xa35.google.com [IPv6:2607:f8b0:4864:20::a35]) (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 CEFAD3A0EB2 for <dmarc@ietf.org>; Wed, 27 Jan 2021 12:10:49 -0800 (PST)
Received: by mail-vk1-xa35.google.com with SMTP id m25so810905vkk.6 for <dmarc@ietf.org>; Wed, 27 Jan 2021 12:10:49 -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 :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; d=1e100.net; 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: <bef64e7a-571b-a73f-dc91-aa402ca320c8@taugh.com> <1655426.E2olI3CrJK@zini-1880> <c39916f8-33f5-9876-c018-53085f5cc8f5@tana.it> <3776619.NdRDDhGtae@zini-1880> <81ab38a1-4b0a-3845-fc8c-7d49d7850c26@tana.it>
In-Reply-To: <81ab38a1-4b0a-3845-fc8c-7d49d7850c26@tana.it>
From: "Murray S. Kucherawy" <superuser@gmail.com>
Date: Wed, 27 Jan 2021 12:10:37 -0800
Message-ID: <CAL0qLwZgB4iVSudbJeh8NGiKd1232SBTy4YDG6Zj-=LV+1m6Uw@mail.gmail.com>
To: Alessandro Vesely <vesely@tana.it>
Cc: IETF DMARC WG <dmarc@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000f3098205b9e75d65"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/rrgj4YgioZE1VjDG-jSzLh4_Usw>
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, 27 Jan 2021 20:10:51 -0000

On Wed, Jan 27, 2021 at 9:26 AM Alessandro Vesely <vesely@tana.it> 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
me.

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

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
> MAIL
> 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