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 14525 invoked from network); 11 Nov 2023 16:59:09 -0000 Received: from mx1.math.uh.edu (129.7.128.32) by inbox.vuxu.org with ESMTPUTF8; 11 Nov 2023 16:59:09 -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 1r1rJx-00HPNR-2q for ml@inbox.vuxu.org; Sat, 11 Nov 2023 10:58:57 -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 1r1rJx-00137w-0s for ml@inbox.vuxu.org; Sat, 11 Nov 2023 10:58:57 -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 1r1rJu-00137n-1h for ding@lists.math.uh.edu; Sat, 11 Nov 2023 10:58:54 -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 1r1rJo-00HPMx-1i for ding@lists.math.uh.edu; Sat, 11 Nov 2023 10:58:54 -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=yDCgaFRRxAopkwem2fGPCba2fEn9xHH73Bx9gsj/UXA=; b=Hq7zDoi1yi94bTDOl3xRHiw3fd aBI9ORNZ2BAxyrKzjjtEeNTIFaHwYlQCVFw++zZmT3JwwAt6VaLAf4Y/6n1btVW7zO4Ajt5RVSqd3 OUJJGP4n30bbHwbHLvF/igdR8iNc3RW81BrzYFmW53dRyl+PRmZIWY0XTjPsY1aofHoM=; 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 1r1rJg-00074l-HN for ding@gnus.org; Sat, 11 Nov 2023 17:58:43 +0100 Received: by s1.lexort.com (Postfix, from userid 10853) id 6989C4106FC; Sat, 11 Nov 2023 11:58:37 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=lexort.com; s=mail; t=1699721917; bh=oqbUBDM6veaYD8mROnwhuh3jtILvVG+p3G4jiwfETIQ=; h=From:To:Cc:Subject:References:Date:In-Reply-To; b=ORPV1SjVTqhlaY5bpDInqY09pTV9o2qnkj+0aYaNY5nUqJI2BZlT5u42Vro8ieqrZ lwfGlpUsIpe7znDX6kevS4gPsCjUldHeBxAw6op9tv0d87QT8wWiWk8CkSpcNKLwYr XAswLMOhe3aQuQyrXXl1LMIWDxvU1eqdVvURu0GY= 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> <87ttpy6xnr.fsf@ericabrahamsen.net> OpenPGP: id=098ED60E Date: Sat, 11 Nov 2023 11:58:37 -0500 In-Reply-To: <87ttpy6xnr.fsf@ericabrahamsen.net> (Eric Abrahamsen's message of "Mon, 06 Nov 2023 19:38:00 -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: > Greg Troxel writes: >> 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. > > I have a solution! Potentially. When a user runs SDb, we first prompt > "Edit original (bounced) message before sending?" > > If the user chooses "no", we resend immediately using `message-bounce', > including the original Message-ID and all that jazz (though still > respecting `message-ignore-bounced-headers'). If the user chooses "yes", > we sneakily delegate to SDe, dumping them in a *Unsent Message* buffer. > This way the user is the one deciding "is this a new message or not?" If > they decide to edit, they're essentially sending a new message. > > WDYT? That could be ok. I personally feel that SDb without editing is so rare as to not be worth accomodating. And, the headers that are included are potentially added by other systems. I would like to see only headers that were present when the message was sent from gnus (or whatever MUA) to the originating MTA. Which makes me think that all of this should tend to keep fewer headers, and not keep those added by intermedaite systems. However this is getting unreasonably complicated and the idea of explicitly dropping troublesome headers and hoping that the residual issues are less than the effort it would take to resolve this 100% perfectly.