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

Douglas Foster <dougfoster.emailstandards@gmail.com> Mon, 26 June 2023 17:33 UTC

Return-Path: <dougfoster.emailstandards@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 B6484C14CF0D for <dmarc@ietfa.amsl.com>; Mon, 26 Jun 2023 10:33:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.094
X-Spam-Level:
X-Spam-Status: No, score=-2.094 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, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=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 ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SZHO9sJrKg5B for <dmarc@ietfa.amsl.com>; Mon, 26 Jun 2023 10:33:07 -0700 (PDT)
Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com [IPv6:2a00:1450:4864:20::134]) (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 133F3C14F721 for <dmarc@ietf.org>; Mon, 26 Jun 2023 10:33:07 -0700 (PDT)
Received: by mail-lf1-x134.google.com with SMTP id 2adb3069b0e04-4f122ff663eso4670834e87.2 for <dmarc@ietf.org>; Mon, 26 Jun 2023 10:33:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1687800785; x=1690392785; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=C8ycH657J26gPSTaLDsSlWDFnliW7yrGBVMlTar8NZU=; b=YVStDuNV+ZrxUKCTr6i0ubmh/FOnClcP4k7FUUi0lzXPw5Zi/iZJORcNSJvskkGwIx poY6flNcBBE6JRcJPJ49bHu0dhiZQrKeM4iPinRWP5gbDnfCPNo7SlPlTaHu5SnKJHlM iYo281hL0FycvFl/U2KERUL9MVMCD4GsSogABU9EYHOZglTy/hLn5cD9G1t/bQbPy12Y XUJw1kHSbPQgef/dbjnTAWGy6/jg5ASPneXHS3uRJfrvS47LR431iUv/U3LN5J3bH77f V160e7xDwRywzUAEyLVnM7kAwmPmqGqaI45X0x2qp7hVunCqAOlYbToWfLnHnUjaCW4x /EiA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1687800785; x=1690392785; 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=C8ycH657J26gPSTaLDsSlWDFnliW7yrGBVMlTar8NZU=; b=k0O0rkTXPDln5xGJKztjLtxmb5XIx0HALEqEZXiaEVbJQ8w4qMSN3POwZ0jRdR6qng aElMd/e7PakunTVsC+JgsiJtdl6VC/br9If8udVSLeIRhOJq8Y5cCLqwMqP+pBuLPGZg f9VDIzGr1ohpnKKAkuZMbqdQYPHPP/XyRLgZQv7HkL0VzSl0W3oDfpgLMDb/loLdfnxN TI5X6alhquESceO8kVwN5zrInf+rhKQ99LlCkAhHT/u+lwY3nqtdkyBTy4DiIEweDYpO nsKKcuSQhtxW5X/mK2A9MzIllXVLaaxRbLyHuMaZNPesChMyWGPRElhWDEl0DHPyi46I 3lpQ==
X-Gm-Message-State: AC+VfDyCZURhIWHUFElJqMafjtUA5zFlWvPI92+Uw5EZOet9KjhxbsJl ZiMTmqo8/x8jnjZdJblF34W0kPEw0ulRnTaZ8S9hM2O6
X-Google-Smtp-Source: ACHHUZ4s5cGn2PGHTxbVww7MID2TxaK6r9zzHuQepv0ofoleSlwBX9xrag7CSDzJDM3QxOyREHK8s7TyRnACxtjwyww=
X-Received: by 2002:a19:5003:0:b0:4f8:5e65:b61b with SMTP id e3-20020a195003000000b004f85e65b61bmr13603291lfb.65.1687800784781; Mon, 26 Jun 2023 10:33:04 -0700 (PDT)
MIME-Version: 1.0
References: <20230623021810.E5F8DF9B3B94@ary.qy> <6495D504.4090809@isdg.net> <839aa10b-f7fa-c7a2-76db-6441189afca2@dusatko.org> <CALaySJ+gcVvpzJcrpUbOkOvjUFAhzw=pZovpZC7BhW_x7VW7nA@mail.gmail.com> <b78cb14a-d641-fabd-a67c-f099b8fae3f9@tana.it>
In-Reply-To: <b78cb14a-d641-fabd-a67c-f099b8fae3f9@tana.it>
From: Douglas Foster <dougfoster.emailstandards@gmail.com>
Date: Mon, 26 Jun 2023 13:32:53 -0400
Message-ID: <CAH48Zfwm4YZ1Px4NG-Vo8n-S1Gj7vps=JrYw0-zyHx4N8qWhkw@mail.gmail.com>
To: Alessandro Vesely <vesely@tana.it>
Cc: IETF DMARC WG <dmarc@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000003a857e05ff0bbe07"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/ujLOSy6_xI_mDIKIbtZidW0tCS0>
Subject: Re: [dmarc-ietf] easier DKIM, 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: Mon, 26 Jun 2023 17:33:07 -0000

DKIM+SPF says "our domain, including subdomains covered by this policy,
will never use an ESP".  (Since most ESP messages pass SPF based on the ESP
domain)

This seems unlikely to be a reliable assertion, so the effect on
disposition is likely to be strongly negative, even without the effect on
forwarders.  I oppose.

Similarly, SPF only seems unlikely to provide improved dispositions.
Evaluators are unlikely to find it worth honoring.

All I think we need is a tag that says,nl "ignore SPF if you understand
DMARC" .   Since only DMARC-aware evaluators will be looking for the policy
which contains the tag, I see no obstacles.



On Mon, Jun 26, 2023, 12:14 PM Alessandro Vesely <vesely@tana.it> wrote:

> On Mon 26/Jun/2023 14:51:34 +0200 Barry Leiba wrote:
> > If we consider this sort of thing, I want to push to keep one thing
> > off the table:
> >
> > Saying that SPF *and* DKIM *both* have to pass is a VERY BAD approach.
> > Let's please just remove that from consideration.  It has not been in
> > DMARC up to this point, and it would be really bad to add it.
> > Deliverability would be worse than ever because we would get the worst
> > of both: fragility of SPF when messages are relayed/forwarded, *and*
> > problems caused by misconfigurations in *either* SPF *or* DKIM.
>
>
> I agree it'd be an extreme setting.  It could only make sense in very
> extreme
> cases.  However, in those cases it might make sense.
>
> In addition, if ARC-driven forwarding setups will gain the ability to
> override
> DMARC, at least for established forwarding paths, the forwarding
> prohibition
> would then be softened.  After all, spf-all requires a comparable behavior
> (except that SPF allows intermediate results) and many domains use it
> satisfactorily.
>
> The conundrum is protecting users from self-injury versus unleashing the
> full
> power of the combined mechanisms.
>
>
> > I can accept some mechanism for the sender to say "SPF only", "DKIM
> > only", or "either SPF or DKIM".  I cannot except a version of DMARC
> > where *both* must pass.
>
>
> Frankly, I cannot imagine the usefulness of auth=spf only.  People who
> don't
> implement DKIM or don't like it don't bother publishing a policy to
> explicitly
> excluding it.  It's enough not to sign.  Excluding DKIM would be useful if
> keys
> have been compromised, an they have a long lifetime while, by chance,
> DMARC
> policy is given with TTL 3600.  It doesn't seem to be realistic.
>
> Still, I'd allow that possibility for symmetry reasons.
>
>
> Best
> Ale
> --
>
>
>
>
>
>
>
> _______________________________________________
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>