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 32577 invoked from network); 5 Nov 2023 15:56:04 -0000 Received: from mx1.math.uh.edu (129.7.128.32) by inbox.vuxu.org with ESMTPUTF8; 5 Nov 2023 15:56:04 -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 1qzfTg-00D7lZ-0R for ml@inbox.vuxu.org; Sun, 05 Nov 2023 09:56:00 -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 1qzfTf-000kBI-1n for ml@inbox.vuxu.org; Sun, 05 Nov 2023 09:55:55 -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 1qzfTc-000kB9-2G for ding@lists.math.uh.edu; Sun, 05 Nov 2023 09:55:52 -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 1qzfTY-00D7lG-1E for ding@lists.math.uh.edu; Sun, 05 Nov 2023 09:55:52 -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: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:In-Reply-To:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=txTCjFvxIVAS44OxNNL7O2Cyrx8MEemHhYsw2GFFX7A=; b=MDdw+GV0OtNy8R1YR1WtwJWdfo 5oro8w1uc6YG/nmWRWbJ0HsK9VxQcPuYdBjiumBt8BcsHmrq86fkfO9lJEfFPz2lgfbEuWHW9JGqj 8GRHXgZwDUETAxJEDL7l/MVrgQ5sGMyQTHeg4EKM06WfKpmL1bzOGoVHFTupySpykh0M=; 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 1qzfTQ-0006I0-7L for ding@gnus.org; Sun, 05 Nov 2023 16:55:43 +0100 Received: by s1.lexort.com (Postfix, from userid 10853) id 11F3A4106EB; Sun, 5 Nov 2023 10:55:37 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=lexort.com; s=mail; t=1699199737; bh=hQiYdmCEDJ5707U8uqrNEsKo99TpstCo/RGldFu4B2E=; h=From:To:Cc:Subject:References:Date; b=iDcucgfcYZttvmfEuRZnh4CFBstc0Kpex7v0bVNSx+xcJkaXbTW3JW1nBXuG0YbAk NbStZ6Itnjw4NzwZiMlVGAxXmzU070yigwstqq4cjaqIA2w+ui5Etcx9DRd8pfW0wR PUPSdpd/TtD2kR7Sz/CMO9buwOzywGQiqISKb+wQ= From: Greg Troxel To: Eric Abrahamsen Cc: ding@gnus.org Subject: Re: resending bounces: DKIM and Message-ID: References: <87msvu8m4w.fsf@ericabrahamsen.net> OpenPGP: id=098ED60E Date: Sun, 05 Nov 2023 10:55:37 -0500 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: >> The proposal is to fix this by: >> >> * in gnus >> - adding a list of headers which should be removed from bounce >> messages when doing gnus-summary-resend-bounced-mail > > I believe this is called `message-ignored-bounced-headers'! It does not > currently include DKIM-Signature, but maybe it should. I haven't > actually tested this, but looking at the code I believe it should take > effect in this situation. 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. >> - set the list to Message-ID and DKIM-Signature to start with > > 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. > What do you think? 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. I think: Some people treat messages with the same message-id as dups. I am not sure that's 100% legit but I know it happens. If nobody got the message, it doesn't really matter if the new message-id is the same or not. If the message is identical, and somebody got it twice (because their addr was right the first time), it might be marginally better to have the same message-id. But doing this right requires keeping track of the original buffer contents and later dropping message-id if there is even 1 byte different, and that just feels too hard/fragile to let somebody filter a dup in such an edge case. 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.