Re: resending bounces: DKIM and Message-ID:

[Greg Troxel <gdt@lexort.com>]

Dan Christensen <jdc@uwo.ca> writes:

> Eric wrote:
>
>>>> 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.
>
> I like that solution.
>
> I don't like the status quo, since when you do `S D b', it drops you
> in a message buffer, inviting you to edit it, but then makes the
> assumption that you won't edit it (by preserving the Message-ID, etc).
>
> My second choice is to just assume that it may be edited, and
> remove the appropriate headers.

I agree mostly except I lean to "assume edit".



Really there are 2 orthogonal choices:

  "extract a bounce and prepare to resend" vs "resend a message"

and

  "don't edit" vs "edit"

except that "resend" more or less is always edit in that you choose a
new destination and you add Resent-From: and Resent-To: headers.  (If
these are covered by DKIM you need to remove DKIM_Signature.)


This argument leads to "offer choice to edit or not and prune headers on
the edit branch", for both SDb and SDe.

Maybe edit by default and ^U prefix arg to not edit?  (Only an emacs user
could think that's reasonable!)