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 6956 invoked from network); 5 Nov 2023 19:30:43 -0000 Received: from mx1.math.uh.edu (129.7.128.32) by inbox.vuxu.org with ESMTPUTF8; 5 Nov 2023 19:30:43 -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 1qzipU-00DEJs-2s for ml@inbox.vuxu.org; Sun, 05 Nov 2023 13:30:40 -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 1qzipU-000kUW-0o for ml@inbox.vuxu.org; Sun, 05 Nov 2023 13:30:40 -0600 Received: from mx2.math.uh.edu ([129.7.128.33]) by lists1.math.uh.edu with esmtp (Exim 4.96.2) (envelope-from ) id 1qzipR-000kUN-18 for ding@lists.math.uh.edu; Sun, 05 Nov 2023 13:30:37 -0600 Received: from quimby.gnus.org ([95.216.78.240]) by mx2.math.uh.edu with esmtps (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.96.2) (envelope-from ) id 1qzipL-00DNV1-2A for ding@lists.math.uh.edu; Sun, 05 Nov 2023 13:30:37 -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: In-Reply-To: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=G1PopVHkQVwBA+mqhtuOndUkdW8SMeShRVpax3NK2pU=; b=G+Pw1rFGIdRCDlN4V4S29g/Vmg mCaWwhR7DuN6WYELMFk4t4tVPs6IcqDXWuE1IzBQpwYtX7JoxYKIJls91jUfCRc357CKoC5XujOez jVf6l6acMW5vqM1jzZmdyEo1zLpou1TuqZVGoK+nPHfHxo+xpwzUBiQ3wyYzf9hvQ0As=; Received: from mail.ericabrahamsen.net ([52.70.2.18]) by quimby.gnus.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1qzipE-0007xF-0L for ding@gnus.org; Sun, 05 Nov 2023 20:30:26 +0100 Received: from localhost (71-212-21-65.tukw.qwest.net [71.212.21.65]) (Authenticated sender: eric@ericabrahamsen.net) by mail.ericabrahamsen.net (Postfix) with ESMTPSA id DD1A2FA0C0; Sun, 5 Nov 2023 19:30:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericabrahamsen.net; s=mail; t=1699212621; bh=G1PopVHkQVwBA+mqhtuOndUkdW8SMeShRVpax3NK2pU=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=Wc7S6b/BM7q4A3v0r4zeSyR1FXJGIJ8flVXRU35SNy7IOXQ+5J24OrDLj92kAI8PC c5SDyrigCPQ/F8daT0Xln5bXkCNAsPoFKTBIbXsa9+sLsnbLY1gq7uideSXbpzYpG1 yUOXvjO3oW4Hkuz3K8woCypYKyFqAkMG4ZjYxlRs= From: Eric Abrahamsen To: Greg Troxel Cc: ding@gnus.org Subject: Re: resending bounces: DKIM and Message-ID: In-Reply-To: (Greg Troxel's message of "Sun, 05 Nov 2023 10:55:37 -0500") References: <87msvu8m4w.fsf@ericabrahamsen.net> Date: Sun, 05 Nov 2023 11:30:19 -0800 Message-ID: <877cmw80c4.fsf@ericabrahamsen.net> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain List-ID: Precedence: bulk Greg Troxel writes: > 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. 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? >>> - 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. 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. >> 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. 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. > 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. Yeah, I don't think we can assume/enforce one interpretation or the other. > 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. I agree we shouldn't try a DWIM thing here. > 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. 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". 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. That's as far as I've gotten...