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=0.2 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.4 Received: (qmail 21881 invoked from network); 19 Nov 2023 19:45:12 -0000 Received: from mx1.math.uh.edu (129.7.128.32) by inbox.vuxu.org with ESMTPUTF8; 19 Nov 2023 19:45:12 -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 1r4nj5-001tNk-1u for ml@inbox.vuxu.org; Sun, 19 Nov 2023 13:45:03 -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 1r4nj5-001PVR-0N for ml@inbox.vuxu.org; Sun, 19 Nov 2023 13:45:03 -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 1r4nj2-001PVI-1H for ding@lists.math.uh.edu; Sun, 19 Nov 2023 13:45:00 -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 1r4nix-005b4P-1U for ding@lists.math.uh.edu; Sun, 19 Nov 2023 13:45:00 -0600 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:Mime-Version:References:Message-ID:Date:Subject: From:To:Sender:Reply-To:Cc: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=aC29yM6W7CV5ktXbowi6E9fBVB7VbZVBWuvuuFzwB8g=; b=Blu11qic/SuzIjfkV5o2/pb+yu ghKq/0lg4k5hDQSvfrFHjRZGADbd5Ren++MSWiHhFCSTGXaEaScB4dTbmu1MxNmckdw7ktsC3r3Rx hjpqK3SMYpyDU1og+CmAn3z7212amicQlF9aum6VXxjD6GnurPo0l82Hr8Ye+MInYd9E=; Received: from ciao.gmane.io ([116.202.254.214]) by quimby.gnus.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1r4niq-0006M4-M0 for ding@gnus.org; Sun, 19 Nov 2023 20:44:51 +0100 Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1r4nio-0006Qz-Jd for ding@gnus.org; Sun, 19 Nov 2023 20:44:46 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ding@gnus.org From: Eric Abrahamsen Subject: Re: resending bounces: DKIM and Message-ID: Date: Sun, 19 Nov 2023 11:44:39 -0800 Message-ID: <8734x1ply0.fsf@ericabrahamsen.net> References: <87msvu8m4w.fsf@ericabrahamsen.net> <877cmw80c4.fsf@ericabrahamsen.net> <87ttpy6xnr.fsf@ericabrahamsen.net> Mime-Version: 1.0 Content-Type: text/plain User-Agent: Gnus/5.13 (Gnus v5.13) Cancel-Lock: sha1:y/P/F6dGrYLJ8vfgV35i0+7qFlQ= List-ID: Precedence: bulk Greg Troxel writes: > 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. At this point it feels like we're just turning SDb into SDe, except an SDe that works on a received bounce rather than the user's original sent message. I understand that all this is annoying, and points to a real issue, but it also doesn't quite seem worth disturbing compatibility/expected behavior. WDYT?