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.1 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, 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 17072 invoked from network); 7 Nov 2023 03:38:39 -0000 Received: from mx1.math.uh.edu (129.7.128.32) by inbox.vuxu.org with ESMTPUTF8; 7 Nov 2023 03:38:39 -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 1r0Cv8-00E7Ge-19 for ml@inbox.vuxu.org; Mon, 06 Nov 2023 21:38:34 -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 1r0Cv7-000p76-2e for ml@inbox.vuxu.org; Mon, 06 Nov 2023 21:38:29 -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 1r0Cv6-000p70-1A for ding@lists.math.uh.edu; Mon, 06 Nov 2023 21:38:28 -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 1r0Cv2-00E7GJ-0b for ding@lists.math.uh.edu; Mon, 06 Nov 2023 21:38:28 -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=FDG9oKZwKFXe5Uq3/jkP1J9g2vlmyWeEmP1XLkoj5j8=; b=Jwm5JE8VEivaa8XzK/s3sXbVBW ZF6dBODu6w9GjTjDWqMxZ0ewotsmjeeT5Eb1iDlfjGlXVmimMLNEjEiNjAClX8PhmVE/ZWowTq0Nw fRpJ+6TWqjjJYWTqfenAJ1TG/woJ6rg16mecjeb793jLwZP440VX2xXlZJx2JtcfnJyA=; 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 1r0Cuq-0003sM-OR for ding@gnus.org; Tue, 07 Nov 2023 04:38:14 +0100 Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1r0Cup-0000DA-8i for ding@gnus.org; Tue, 07 Nov 2023 04:38:11 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ding@gnus.org From: Eric Abrahamsen Subject: Re: resending bounces: DKIM and Message-ID: Date: Mon, 06 Nov 2023 19:38:00 -0800 Message-ID: <87ttpy6xnr.fsf@ericabrahamsen.net> References: <87msvu8m4w.fsf@ericabrahamsen.net> <877cmw80c4.fsf@ericabrahamsen.net> Mime-Version: 1.0 Content-Type: text/plain User-Agent: Gnus/5.13 (Gnus v5.13) Cancel-Lock: sha1:HBgIV/Mkw9NYjhpJndhncrgZVO8= List-ID: Precedence: bulk Greg Troxel writes: > 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.) I feel like Gnus is willing to be the last one to turn off the lights on a lot of network technologies. >>>> 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. Also, SDe's behavior is to obey a (short) _preserve header_ list, in contrast to SDb, which has a (equally short) _remove header_ list. So in the SDe case, most headers will be dropped. >>> 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? What I was saying is: in the SDe case it isn't, but in the SDb case it is. But! See below. >> 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. 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?