Re: [dmarc-ietf] Overall last-call comments on DMARC

"Murray S. Kucherawy" <superuser@gmail.com> Wed, 03 April 2024 16:50 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 2CE11C14F6B6 for <dmarc@ietfa.amsl.com>; Wed, 3 Apr 2024 09:50:11 -0700 (PDT)
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, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 IQYEE3zsjVwt for <dmarc@ietfa.amsl.com>; Wed, 3 Apr 2024 09:50:06 -0700 (PDT)
Received: from mail-ej1-x62b.google.com (mail-ej1-x62b.google.com [IPv6:2a00:1450:4864:20::62b]) (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 ABE4DC14F6B5 for <dmarc@ietf.org>; Wed, 3 Apr 2024 09:50:06 -0700 (PDT)
Received: by mail-ej1-x62b.google.com with SMTP id a640c23a62f3a-a474df36309so1675066b.0 for <dmarc@ietf.org>; Wed, 03 Apr 2024 09:50:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1712163004; x=1712767804; darn=ietf.org; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=Vv0nahlIJM93AUictg39OGHjudIO/j6AJRRxMhtuOJQ=; b=h4Gv9e6DYrTdxina9718DYttQgLnw49vrZYh0E1Wu/kuc8q3FKeVT0ALrUgIQcU9I+ 9byxo4A2KIsJpxQZ3UgpRCIZZkaco4AIvJMvA69sWdttQrs8nr/mzQwJWOYeyE30LQh3 YFnNmoX2z9G2i5Xi05TEupiE6TAjCgV3NPgehAWgNdyzoDvSmhnhoVs5C4DPGB/X71B6 EFPUnqv7qJTxgntWb81JI4E0hsAfoLpjoFT2688i2QhGuZcCkzkzQ15iq0Yg2wFe/HY7 uDyTAiNK+5X54qI/a1W23gJmv7Siv/ViuTBOqVbEH5WGmMETP7+llVXRVYAb54TxjRcP 7NqQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712163004; x=1712767804; h=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=Vv0nahlIJM93AUictg39OGHjudIO/j6AJRRxMhtuOJQ=; b=jPZQGHLi2+XrIJg13K+pIulc18kxvjmrZZhl1Hqad/FZzM6niMqgnB4ai1P7mRRvIK MYaNXDNFBq9cIyJkLkn+wit7y+/LAsb0LX9+4MbZoDGKc11L8Gren3rF2pBisGZFIZBO 8J2RRwefIBmcqCls4BCpEuyXYYCC3Zm6igZZDps1KxGkSySNq+wpZWJd81y7wpiUvNZn fgGQCEge2shW8th+qEm5uUQELJvuBnunLDIyeSWmS2Kqt/61tkLbSE+ZoRn9I5le55Ok zT1JnrBlJq3pic6j2GEU2ATPzgGJZHGxhmML4LGJ/mvAggCf3/NVdY/VI9hFOE5XKIUB x/jQ==
X-Gm-Message-State: AOJu0YzktZAosVHW6CUdTgg06yfp5rJH551baGuqJF7r6J4vnu9ElVW9 wraiFHW+qV0uPrOKywdzYJVXYqT29YcM9eK4BpG4Z8ilGjjmgW3tbwNxlrKCoEDnnP+kzRObFz3 0fxd/+Swx+GrQYtWXwp3Y/f6G7RhFQLJNU6Q=
X-Google-Smtp-Source: AGHT+IEZ9lTNOy+xK6TTyDlKQ609L7e6Im97bSrg7nocoX89T8I/gdsSOeDuwxl4tlVm30kb7w4COeYiv7xr4k9G/Lw=
X-Received: by 2002:a17:906:2adb:b0:a47:5104:c39 with SMTP id m27-20020a1709062adb00b00a4751040c39mr8640281eje.0.1712163003760; Wed, 03 Apr 2024 09:50:03 -0700 (PDT)
MIME-Version: 1.0
References: <CFEA2796-9213-4847-836B-81E8770973F5@bluepopcorn.net> <5208da1b-ecfb-4d41-8506-a734a27ab3a0@tana.it> <CAL0qLwbnSe77Wdt+M8bi2pBmZFCZjDUQc6je9bjCzP5TQ0N6XA@mail.gmail.com> <49859572-18a4-483b-bb99-62c1c231896e@tana.it> <CAL0qLwZc6idmMra11pVx2bbtk2Em9-vy6+962M7jDWOMnP+UHQ@mail.gmail.com> <1ee6df39-a622-4060-83db-bcc9a7a835d4@tana.it> <CAL0qLwYX_D7S_-Vn9RwwRzwyNO=8=3UVqbP8rz3SCWG4dvGZig@mail.gmail.com> <f5f55a39-127d-4a84-a66b-950379ecb013@tana.it>
In-Reply-To: <f5f55a39-127d-4a84-a66b-950379ecb013@tana.it>
From: "Murray S. Kucherawy" <superuser@gmail.com>
Date: Wed, 03 Apr 2024 09:49:50 -0700
Message-ID: <CAL0qLwZzfnDA=7bwCu26S1SJPEE3hBq929674hH6naKXWuyh5g@mail.gmail.com>
To: dmarc@ietf.org
Content-Type: multipart/alternative; boundary="000000000000a30bd406153403c8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/oJAIsaz-ajOzB_v-llp57f8R1sk>
Subject: Re: [dmarc-ietf] Overall last-call comments on DMARC
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: Wed, 03 Apr 2024 16:50:11 -0000

On Wed, Apr 3, 2024 at 4:16 AM Alessandro Vesely <vesely@tana.it> wrote:

> > So what are you suggesting should go in this document that's in WGLC?
>
> Section 8.6 states the ML problem very well, but it says nothing about the
> way forward.


Here, we agree.  And I'm saying: If we have anything concrete we can say
about the way forward, we really really should include it.  My personal
impression is that we do think we need something here, but there's no
consensus yet on what (possibly due to lack of visible evidence), and it
feels like a hole.


> Some sort of contract or agreement between sender and receiver seems to me
> to be unavoidable if we want to leverage ARC without having a global domain
> reputation system.  We don't have a precise method to do that.  We need to
> experiment and standardize something to that extent, which I hope this WG
> can do after publishing -bis.
>

I know what "contract" means abstractly, but what does this actually look
like to someone that's looking for specific guidance?  The text you have
here, by itself, is vague and I don't think many operators will know what
to do with it.


> Meanwhile, we can mention ARC, in Section 5.8  (minimal text proposed in
> another thread[*]).  How much can we expand that?  For example, can we
> whisper something about the need to trust specific sealers for specific
> streams?
>

If you really need ARC to make all of this work and interoperate with
lists, then I think we need to start talking about how we want to move ARC
out of "Experimental" first so it can become a normative reference.

-MSK, p11g