From: Greg Troxel <gdt@lexort.com>
To: Eric Abrahamsen <eric@ericabrahamsen.net>
Cc: ding@gnus.org
Subject: Re: resending bounces: DKIM and Message-ID:
Date: Sun, 05 Nov 2023 10:55:37 -0500 [thread overview]
Message-ID: <rmipm0ourd2.fsf@s1.lexort.com> (raw)
In-Reply-To: <87msvu8m4w.fsf@ericabrahamsen.net>
Eric Abrahamsen <eric@ericabrahamsen.net> 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.
next prev parent reply other threads:[~2023-11-05 15:56 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-03 12:23 Greg Troxel
2023-11-03 16:14 ` Emanuel Berg
2023-11-03 23:14 ` Eric Abrahamsen
2023-11-05 15:55 ` Greg Troxel [this message]
2023-11-05 19:30 ` Eric Abrahamsen
2023-11-07 0:53 ` Greg Troxel
2023-11-07 1:57 ` Emanuel Berg
2023-11-07 3:15 ` Emanuel Berg
2023-11-07 13:49 ` Greg Troxel
2023-11-07 13:59 ` Emanuel Berg
2023-11-07 3:38 ` Eric Abrahamsen
2023-11-11 16:58 ` Greg Troxel
2023-11-19 19:44 ` Eric Abrahamsen
2023-11-19 21:36 ` Dan Christensen
2023-11-20 0:01 ` Greg Troxel
2023-11-10 16:38 ` Eric Abrahamsen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=rmipm0ourd2.fsf@s1.lexort.com \
--to=gdt@lexort.com \
--cc=ding@gnus.org \
--cc=eric@ericabrahamsen.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).