From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 12783 invoked from network); 7 Nov 2023 01:28:18 -0000 Received: from mx1.math.uh.edu (129.7.128.32) by inbox.vuxu.org with ESMTPUTF8; 7 Nov 2023 01:28:18 -0000 Received: from lists1.math.uh.edu ([129.7.128.208]) by mx1.math.uh.edu with esmtps (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.96.2) (envelope-from ) id 1r0At5-00E3gC-0U for ml@inbox.vuxu.org; Mon, 06 Nov 2023 19:28:15 -0600 Received: from lists1.math.uh.edu ([127.0.0.1] helo=lists.math.uh.edu) by lists1.math.uh.edu with smtp (Exim 4.96.2) (envelope-from ) id 1r0At4-000okr-1B for ml@inbox.vuxu.org; Mon, 06 Nov 2023 19:28:14 -0600 Received: from mx1.math.uh.edu ([129.7.128.32]) by lists1.math.uh.edu with esmtp (Exim 4.96.2) (envelope-from ) id 1r0At1-000oki-1S for ding@lists.math.uh.edu; Mon, 06 Nov 2023 19:28:11 -0600 Received: from quimby.gnus.org ([95.216.78.240]) by mx1.math.uh.edu with esmtps (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.96.2) (envelope-from ) id 1r0ALt-00E3Yu-1B for ding@lists.math.uh.edu; Mon, 06 Nov 2023 18:54:01 -0600 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=gSz9VKXD0+EOxEjWz9TzQzw//KK0QauOccunVUgvtx4=; b=OwcqIuAkXLf3PYEkFqfbHR63Dk aNHkuLPMNf4g0tgmvlKPrALBdRwiym9lazn2daz1c1XS9qZeV7QkP2PXmxxCPzSOLslr82KiDuRJc P3XopVdan4uww9AEmILj51FNUgujYJvARXnuzbMkYYyMYEgW6DSZGo4q7WAQ4TNWIzrk=; Received: from s1.lexort.com ([71.19.148.97]) by quimby.gnus.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1r0ALg-0002jK-R4 for ding@gnus.org; Tue, 07 Nov 2023 01:53:47 +0100 Received: by s1.lexort.com (Postfix, from userid 10853) id 6E52B410711; Mon, 6 Nov 2023 19:53:42 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=lexort.com; s=mail; t=1699318422; bh=lAdLF+YiwVw7xRDX41z0s/xBTYSVJdW2xve0EMhS8/4=; h=From:To:Cc:Subject:References:Date:In-Reply-To; b=AnYfVPBR+hnaPr8onTRhBS+VWv01l0PKklm4TNcgqyx8hlussplbKJWnwVQoRIjB4 kIGm+mBLI/rvhBXeUq0Dl/kDgqploJ4YfhGojCnHJpgCEayq/WMl4gUZzj/ePWotbg vs7Jswqv5kvLRHHoATp4MPkftMAtgpwBx5T6WXo4= From: Greg Troxel To: Eric Abrahamsen Cc: ding@gnus.org Subject: Re: resending bounces: DKIM and Message-ID: References: <87msvu8m4w.fsf@ericabrahamsen.net> <877cmw80c4.fsf@ericabrahamsen.net> OpenPGP: id=098ED60E Date: Mon, 06 Nov 2023 19:53:42 -0500 In-Reply-To: <877cmw80c4.fsf@ericabrahamsen.net> (Eric Abrahamsen's message of "Sun, 05 Nov 2023 11:30:19 -0800") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain List-ID: Precedence: bulk Eric Abrahamsen writes: >> Wow, exactly the right thing. Yes, I added DKIM-Signature in .emacs: >> >> (setq message-ignored-bounced-headers >> "^\\(Received\\|Return-Path\\|Delivered-To\\|DKIM-Signature\\):") >> >> and now SDb omits it. >> >> I would say that the default value should be changed to include >> DKIM-Signature. If the message is altered at all it becomes invalid, >> and the new message should get signed the same way, so having two valid >> signatures one of which has an incorrect time is just not helpful. I >> cannot think of ever wanting to keep it. It's not quite like Received >> but it's close. > > Great! And yes, let's add it to the default. I poked around briefly for > other signing-type headers that we might want to delete, but haven't > come up with anything that puts an actual signature in the headers. > Hashcash, maybe? I suppose you could add hashcash, but I perceive hashcash to be historical. Is anybody still using it? (I used to have it configured both generated and scored on receipt.) >>> This is deeper in the protocol weeds than I usually go, so this is a bit >>> tentative, but I will note that there's a separate >>> `gnus-summary-resend-message-edit' command, which will not preserve the >>> Message-ID header. I think there's an argument to be made that, if >>> you're re-sending the bounced the message, it is in fact the same >>> message over again. If you're changing the "To:" or other headers, on >>> the other hand, that sounds like a new message, and you should be using >>> "S D e" instead. >> >> Interesting point. When I run that on the bounce, I am queued up to >> re-send the bounce message, not the original message that was included >> in the bounce. > > The command is supposed to be run on your own original message (in Sent > or wherever), not the bounce that you got back. I think if you do that > it should behave correctly. Sure, and it should probably also remove DKIM, but because it's more likely from Sent it probably won't be there. >> I would say that 99% of the time, when you are resending a bounce, you >> are fixing what you did wrong that caused it to bounce, like mistyping a >> To/CC. In which case the new message is.. a new message. In rare >> cases, you have fixed something else (like the receiving system such as >> subscribing or your MTA) and are sending the exact same message. > > Okay, I'd been assuming the most common case was the not-yet-subscribed > case. Or some other transient system-level failure, ie not an actual > change to the message itself. My experience is that almost all bounces are because I typed something wrong. Transient failures are once in a blue moon. Not being subscribed, subscribing and resending (vs just giving up) is rare for me. But I believe this is different for different PEBKAC specimens. >> If some people got the message and some didn't, because the original >> sender typoed one of the addresses, then the question is if the >> original successful recipients should get >> A) a 2nd copy with the same message-id and updated headers >> B) a 2nd copy with a new message-id and updated headers >> C) nothing >> D) something else >> I lean to B, because they should realize a typo was fixed, especially >> if the person added [resending due to address typo], and should thus >> delete the first and keep the second for replies. > > I'm still coming back to the distinction between "resend-edit" and > "resend-bounced". In terms of the commands themselves, I think they do > the right thing: The first essentially creates a new message from an > earlier template (which fits with the fact that it's called from your > "Sent" folder/group), meaning that it regenerates most of the headers. But still, the question is: Is that new message the same or not? > The second command just repeats an earlier message, and preserves all > the headers it can. To me it feels right that the first case gets a new > Message-ID, and the second case doesn't. > > The problem is that, in your example situation, the message has been > bounced, but the appropriate command to deal with it is actually > "resend-edit". It's really not that, but gnus-summary-resend-bounced-mail-edit, a variant where you can change it, vs a variant where you can't (readonly). The current code lets you edit it, and I 99% do edit it, so that seems normal. > In a sense, it's a documentation issue: "Use `resend-bounced' unless you > need to edit anything in the message, in that case use `resend-edit'". > But it's unreasonable to expect anyone to keep all that in mind. Yes, and it's further unreasoable that there are really 4 options as a product of two choices modify vs not extract from bounce vs operate on self-bcc or Sent I'm basically saying that wanting to resend a bounce exactly feels rare, and that even if it is the same, you want a fresh message-id and a fresh dkim signature so that you don't have problems from state created perhaps wrongly by the original message.