[Ietf-dkim] Re: IETF 124 DKIM Agenda

"Inveigle.net" <cs@inveigle.net> Thu, 30 October 2025 18:25 UTC

Return-Path: <cs@inveigle.net>
X-Original-To: ietf-dkim@mail2.ietf.org
Delivered-To: ietf-dkim@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id D80C27F054BA for <ietf-dkim@mail2.ietf.org>; Thu, 30 Oct 2025 11:25:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=inveigle.net
Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HDHguNtPp3ll for <ietf-dkim@mail2.ietf.org>; Thu, 30 Oct 2025 11:25:58 -0700 (PDT)
Received: from akl.inveigle.net (akl.inveigle.net [103.187.6.191]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 904677F052CA for <ietf-dkim@ietf.org>; Thu, 30 Oct 2025 11:25:50 -0700 (PDT)
Received: by akl.inveigle.net (OpenSMTPD) with ESMTP id 8e227bc1 for <ietf-dkim@ietf.org>; Thu, 30 Oct 2025 18:25:41 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=inveigle.net; h= message-id:date:mime-version:subject:to:references:from :in-reply-to:content-type:content-transfer-encoding; s= thingamajig; bh=S9s5axHRWRQM5PX3vSbURJ3R9eXlgPQyIFSqnoA3v6c=; b= eXOAZBD751syeBQiQUourhmstOnq+w5S72MauauMtoaXvGChLYKPw2gq3vuRL4XF VOLwJaAAz3WeFjiv1Rj/P7GIejH4yzF4ujl7Y/TYlxJQMy1hOUCYYdNaP+fSXMhR BEMdVrpU+khD1EHrD/6Ec2jb2pEs2/etT2aVmheDodGZLQ+L804TsCinoayMnj30 u3kY8PdMx4DT85iarPjN5L6MSUdDPkbsJVu+mUKP72txqQ3nF5uQI0oQG9t764LS qblPKATj8VMxCuh2Ow3yPz1WIPIgkiOzUHg5ntt1FFJeZrHqrvx1WGDLklcSX/Jt iXI9DW8ayeJKYZVOyAChZQ==
Received: from [10.0.1.24] (<unknown> [10.0.1.24]) by akl.inveigle.net (OpenSMTPD) with ESMTPSA id 2c86a80c (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO) for <ietf-dkim@ietf.org>; Thu, 30 Oct 2025 18:25:41 +0000 (UTC)
Message-ID: <244b3f76-c8a7-43a3-9d72-450cde71044f@inveigle.net>
Date: Fri, 31 Oct 2025 07:25:32 +1300
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
To: ietf-dkim@ietf.org
References: <CAL0qLwaCEJgM57atMbGxQz=z+_BxP9c9uQatCJoQG+mUssVDog@mail.gmail.com>
Content-Language: en-US
From: "Inveigle.net" <cs@inveigle.net>
In-Reply-To: <CAL0qLwaCEJgM57atMbGxQz=z+_BxP9c9uQatCJoQG+mUssVDog@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Message-ID-Hash: XMCN2CVYULSR4KL5MS2W56XPFGHSZZCC
X-Message-ID-Hash: XMCN2CVYULSR4KL5MS2W56XPFGHSZZCC
X-MailFrom: cs@inveigle.net
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-ietf-dkim.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [Ietf-dkim] Re: IETF 124 DKIM Agenda
List-Id: IETF DKIM List <ietf-dkim.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-dkim/Z8rO4k_2BIBqB3SAdmz4QDlEDH8>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf-dkim>
List-Help: <mailto:ietf-dkim-request@ietf.org?subject=help>
List-Owner: <mailto:ietf-dkim-owner@ietf.org>
List-Post: <mailto:ietf-dkim@ietf.org>
List-Subscribe: <mailto:ietf-dkim-join@ietf.org>
List-Unsubscribe: <mailto:ietf-dkim-leave@ietf.org>

It may fall within the draft-gondwana-dkim2-header discussion itself, 
but I would like the opportunity to discuss the alternative approach of 
passing the RCPT TO signature through the envelope and the broader use 
of the proposed ESMTP extension, preferably before delving into the 
details of nd/pp/rt, as those are implementation details that may look a 
little different with an alternate approach.

My motivation is to allow DKIM2 to continue to work with some existing 
use cases as well as simplifying implementation and deployment. I'm 
happy to prepare a few slides to illustrate why I consider this 
alternate approach will achieve these goals.

Regards,
R. Latimer

On 31/10/2025 3:51 am, Murray S. Kucherawy wrote:
> The proposed agenda is available here:
>
> https://datatracker.ietf.org/doc/agenda-124-dkim/
>
> Honest, the formatting was better than what you see; the indenting of 
> bullets didn't stick.  I'll work on fixing it.
>
> Agenda pre-bashing is now open, if anyone has additions or changes to 
> suggest.
>
> -MSK, for the Chair
>
> _______________________________________________
> Ietf-dkim mailing list -- ietf-dkim@ietf.org
> To unsubscribe send an email to ietf-dkim-leave@ietf.org