Re: [Emacs-diffs] /srv/bzr/emacs/trunk r104691: Don't reuse previous Message-id when resending.

[David Kastrup]

Eli Zaretskii <address@hidden> writes:

>> From: Uday S Reddy <address@hidden>
>> Date: Tue, 28 Jun 2011 14:28:52 +0100
>> 
>> Richard's problem was that it got partially sent to some of the 
>> recipients.
>
> No, it was that it bounced from some place on the way.  Which could be
> the local machine or some remote server.
>
> I hope that everyone who participates in this discussion knows what
> the function we are discussing does.  Here's the relevant parts of the
> doc string of rmail-retry-failure:
>
>     Edit a mail message which is based on the contents of the current
>   message.  For a message rejected by the mail system, extract the
>   interesting headers and the body of the original message.  ...  The
>   variable `rmail-retry-ignored-headers' is a regular expression
>   specifying headers which should not be copied into the new message.
>
> And here's what the Emacs manual says about it:
>
>      Sometimes a message does not reach its destination.  Mailers usually
>   send the failed message back to you, enclosed in a "failure message".
>   The Rmail command `M-m' (`rmail-retry-failure') prepares to send the
>   same message a second time: it sets up a `*mail*' buffer with the same
>   text and header fields as before.  If you type `C-c C-c' right away,
>   you send the message again exactly the same as the first time.
>   Alternatively, you can edit the text or headers and then send it.  The
>   variable `rmail-retry-ignored-headers', in the same format as
>   `rmail-ignored-headers' (*note Rmail Display::), controls which headers
>   are stripped from the failed message when retrying it.
>
> So it even isn't necessarily about bounced messages, and the result
> may well be a different message entirely.

If stripping a header like a Message-ID is a sensible thing to do, but
the user might want to unstrip it in rare cases, it might be an option
to place it in a form where Gnus will automatically remove it when
sending, something like

X-Remove: Message-Id: <xxxxx>

Then the user can still, if he considers the removal inappropriate, edit
the message accordingly and let the old header be used in that manner.

-- 
David Kastrup