[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Emacs-diffs] /srv/bzr/emacs/trunk r104691: Don't reuse previous Mes

From: David Kastrup
Subject: Re: [Emacs-diffs] /srv/bzr/emacs/trunk r104691: Don't reuse previous Message-id when resending.
Date: Wed, 29 Jun 2011 23:40:12 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux)

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]