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: Mon, 06 Nov 2023 19:53:42 -0500 [thread overview]
Message-ID: <rmio7g6mlih.fsf@s1.lexort.com> (raw)
In-Reply-To: <877cmw80c4.fsf@ericabrahamsen.net> (Eric Abrahamsen's message of "Sun, 05 Nov 2023 11:30:19 -0800")
Eric Abrahamsen <eric@ericabrahamsen.net> 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.)
>>> 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.
>> 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?
> 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.
next prev parent reply other threads:[~2023-11-07 1:28 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
2023-11-05 19:30 ` Eric Abrahamsen
2023-11-07 0:53 ` Greg Troxel [this message]
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=rmio7g6mlih.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).