Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal

Barry Leiba <barryleiba@computer.org> Fri, 09 June 2023 09:14 UTC

Return-Path: <barryleiba@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 61259C151B06 for <dmarc@ietfa.amsl.com>; Fri, 9 Jun 2023 02:14:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.549
X-Spam-Level:
X-Spam-Status: No, score=-1.549 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.096, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15Dt6rIxR2-c for <dmarc@ietfa.amsl.com>; Fri, 9 Jun 2023 02:14:42 -0700 (PDT)
Received: from mail-ej1-f53.google.com (mail-ej1-f53.google.com [209.85.218.53]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D55C5C1519BD for <dmarc@ietf.org>; Fri, 9 Jun 2023 02:14:42 -0700 (PDT)
Received: by mail-ej1-f53.google.com with SMTP id a640c23a62f3a-977c88c9021so259271066b.3 for <dmarc@ietf.org>; Fri, 09 Jun 2023 02:14:42 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1686302081; x=1688894081; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=zId9AlE/mt6ak+4jWJOgrjl+Pw/+0utCD/Q7egqJRts=; b=kKnphi9j1N2joxQSNM9vjmu0AskVHHjcCzZBPKid0E2cGd75Vsldvc1HAayggVn0RL nYOVhn6V2td6ongLBUiFJmZH2rJ8EyCqfAgliTeI2i7938xbtGwgBfKvLwem3qVw+MUn tRLxdmy4MgdTo07+pyfgk3Q8AC9/Z2bLbeWvhz0jikOhN1fqSfcKvg0l84CSe6pFB36e 3EDzz7iYDPT7atFNfYlLCPMSciOFvQzZTNg/gvm5itb65xBEAQaRBZmCaZzXgmZrDJRg J5QBUKkrAVyfwWsqQQ+awOoTbmdiYWLJ6iUHJrCLnG9f133qsx6EqUE1Cappp8ckH65A tNQQ==
X-Gm-Message-State: AC+VfDxx/2TfZpmzuDdQg+ZCXiUh9Fnab1EaYArlVOhEosl9mDrz2kn2 SdZDTbv3r8VKSb2uiexPJ0kxosPP1T0vvXHJ4GWCEUCd6F4=
X-Google-Smtp-Source: ACHHUZ5x6mzWLWWDbclAM6wOKh0WpCHDoI/ur1qDDV9EgE0XedgU6ry8bks7DtJjxmqYQG+Deu6WZaiiUoILwe2AeGg=
X-Received: by 2002:a17:907:6d0d:b0:97a:13cc:558 with SMTP id sa13-20020a1709076d0d00b0097a13cc0558mr737583ejc.56.1686302081031; Fri, 09 Jun 2023 02:14:41 -0700 (PDT)
MIME-Version: 1.0
References: <30BB83B2-B454-41B8-992B-8E2569802D9C@1und1.de> <CAL0qLwbx6Y=kmB5pQZx8gNqD=rLBYz1vLOX6ngL=wUHHUm0Hjw@mail.gmail.com> <CAOZAAfMtsjcp+aCrwQ2QRc+SHsw3rhwMuTBugRYe44NeiMeKyg@mail.gmail.com> <CALaySJKrXJJXz3pgp85BPswoirhPJtD=uuefVfc9sX1fGkj-iA@mail.gmail.com> <7f854d28-d3b5-fd00-4613-b8baa1217bd7@tana.it>
In-Reply-To: <7f854d28-d3b5-fd00-4613-b8baa1217bd7@tana.it>
From: Barry Leiba <barryleiba@computer.org>
Date: Fri, 09 Jun 2023 10:14:29 +0100
Message-ID: <CALaySJLeJ0xproB6Eg-37sSrNS7XrewUmdKZYVPsVeWddJ90MQ@mail.gmail.com>
To: Alessandro Vesely <vesely@tana.it>
Cc: dmarc@ietf.org
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/Z-WfH9VqRcwubQAMGjPCLOe5JGs>
Subject: Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.39
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: Fri, 09 Jun 2023 09:14:47 -0000

> One case I saw multiple times where DKIM fails while SPF verifies is when the
> message contains a line starting with "from " which some agent changes to
> ">from ".  Some signing software eliminates such lines before signing, but
> that's not in the spec, so one cannot say a signer is defective if it doesn't
> do it.

Have you seen that happen in the MTA relay process (in transit), or
only after final delivery?  I can see that an MDA or a recipient MUA
might do that, but it should *not* happen in transit, so it shouldn't
affect DMARC processing.  Do you have actual examples where an MTA is
making that change and breaking the DKIM sig?

I would be surprised, but, well, I've been surprised many times by
what email software will do.

> What I find nonsensical is to eliminate SPF in order to save DNS queries, given
> that we replaced local PSL lookups with a series of queries.  We cannot do that
> and pretend that SPF is too expensive.

Yes, I agree: the DNS query load is not one of the arguments I'm making.

Barry