From: Eric Abrahamsen <eric@ericabrahamsen.net>
To: ding@gnus.org
Subject: Re: resending bounces: DKIM and Message-ID:
Date: Mon, 06 Nov 2023 19:38:00 -0800 [thread overview]
Message-ID: <87ttpy6xnr.fsf@ericabrahamsen.net> (raw)
In-Reply-To: <rmio7g6mlih.fsf@s1.lexort.com>
Greg Troxel <gdt@lexort.com> writes:
> 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.)
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?
next prev parent reply other threads:[~2023-11-07 3:38 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
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 [this message]
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=87ttpy6xnr.fsf@ericabrahamsen.net \
--to=eric@ericabrahamsen.net \
--cc=ding@gnus.org \
/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).