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

Barry Leiba <barryleiba@computer.org> Thu, 08 June 2023 22:27 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 BA61AC151061 for <dmarc@ietfa.amsl.com>; Thu, 8 Jun 2023 15:27:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.55
X-Spam-Level:
X-Spam-Status: No, score=-6.55 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_HI=-5, 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=ham 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 f2hgL5R4-2HW for <dmarc@ietfa.amsl.com>; Thu, 8 Jun 2023 15:27:13 -0700 (PDT)
Received: from mail-ej1-f54.google.com (mail-ej1-f54.google.com [209.85.218.54]) (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 26DD1C14CEF9 for <dmarc@ietf.org>; Thu, 8 Jun 2023 15:27:13 -0700 (PDT)
Received: by mail-ej1-f54.google.com with SMTP id a640c23a62f3a-973bf581759so203823066b.0 for <dmarc@ietf.org>; Thu, 08 Jun 2023 15:27:13 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1686263231; x=1688855231; 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=OjtONq7ZJPfp7i5PxSZUlxBhwpgYkCmF3Ylij7m8tvY=; b=fzidNIQ8wk+w7FRoLK2JWvI4qp2gzCg75eVfXxM7dyhN5rSpIVRUtMBVnOOhiVv1rE PkDPFuSbGOA3WjOk7N5iTYWQlVt6D5tpoXCcIWDSx7WN8eICiQZ+kI56hFwlprlSMElZ +3VQeulXRHNfa3wDwnltnHdbn3beKJudaSDorYLEgAZ1CHvjwcHjzWO/carNURV/iHR+ azOPOPLEfn5+iAf1QUxHuvTro+OmASSZJW+UJhUy5Gpn+rlvWbP6pVOhiwagq9MBXrPU QL/PwgT4+wpBFEt1wewgFRfoO1hLVOQ0bInLnfP/zsfNXATOyJ04BEJCEE5AWkIN8V9/ MYGw==
X-Gm-Message-State: AC+VfDwXcjE9HEdIDPbtZdcAR+/dqJP2ijvJakW22BtfjGUFgCs4xMKI WDvhJqQEXbXE7OIB/VpQaOm0i2fcv6jOVAfLpok4duswx5q51Q==
X-Google-Smtp-Source: ACHHUZ4oXkr8HcE339gGztV9Yl5y/eTS/CkVvXowHOn3B+uvZyzB+r9SmJGaw2B/zEJLH5zemN3l4gjP4nWDq09Iuwc=
X-Received: by 2002:a17:907:6ea0:b0:965:6aff:4f02 with SMTP id sh32-20020a1709076ea000b009656aff4f02mr561835ejc.41.1686263231316; Thu, 08 Jun 2023 15:27:11 -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> <CAJ4XoYc++Ossx-1oAX6fK12a3v=yz8XhoXKHdNF7-e8p=O3OCA@mail.gmail.com> <CALaySJJU+AAbfYnzm2vHGNzo-BpEHAVUxTw_HmrvDo414MKq+g@mail.gmail.com> <2AC14310-16EC-43A9-B95E-BAE7E5C78FDA@kitterman.com>
In-Reply-To: <2AC14310-16EC-43A9-B95E-BAE7E5C78FDA@kitterman.com>
From: Barry Leiba <barryleiba@computer.org>
Date: Thu, 08 Jun 2023 23:26:59 +0100
Message-ID: <CALaySJLtumxWU2A_ae9oipuebaHn0qDO52TCDYPM1v50NcBq-g@mail.gmail.com>
To: Scott Kitterman <sklist@kitterman.com>
Cc: dmarc@ietf.org
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/9_HEaS5_HGYnXpqyM6qhUyYAQpE>
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: Thu, 08 Jun 2023 22:27:13 -0000

> There are DKIM verification failures for reasons unrelated to DNS failures.  As an example, I
> recently fixed a DKIM validation bug in the library I maintain which was causing a small fraction
> of valid signatures to fail verification since at least 2011.  SPF + DKIM reduces DMARC failures.

Oh, well, I don't buy this one at all: My software might have bugs, so
I have to use multiple mechanisms?  No, you have to fix the software.
"Software might have bugs" is not a reason to put extra complexity
into a protocol.

Would you suggest including two DKIM signatures using different crypto
suites in order to work around possible software bugs?  Would you
suggest putting that into the protocol definition?

> It's true that SPF is not particularly helpful for indirect mail flows, but I read your message as claiming
> using SPF with DKIM causes DMARC verification to be worse for indirect mail flows than when using
> DKIM alone.  Is that right?

What I said was that there is no case where DKIM will fail and SPF
will succeed.  I stand by that statement.  Can you describe a scenario
that breaks DKIM but has SPF still work?

That's assuming the software is working right and one hasn't
configured it wrong, both of which should be fixed.  And if you can't
retrieve a needed DNS record, you need to wait and retry, not try to
put unnecessary redundancy into the protocol.  Unless, of course, you
can show that DKIM is significantly more likely to fail for that
reason than SPF is.

The other thing I said about SPF is that there are cases now where the
SPF records required by the use of major service providers are so
bloated and contain so many IP addresses that they allow spammers who
use those same services to spoof any other customer of the service.
That makes SPF validation weak.  As there's no benefit to it over
DKIM, I don't understand why we'd want to keep it.

We needed SPF when DKIM was less widely deployed.  We thought it was
more useful when we hadn't seen how often it breaks compared with
DKIM.  And one advantage that SPF had -- that it allowed you to reject
a message during the SMTP negotiation, before the DATA command was
accepted -- can't be used if you need to check DKIM as well.

Barry