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

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

[Stefan Monnier]

Why?


        Stefan


>>>>> "Richard" == Richard Stallman <rms@gnu.org> writes:

> ------------------------------------------------------------
> revno: 104691
> committer: Richard Stallman <rms@gnu.org>
> branch nick: trunk
> timestamp: Thu 2011-06-23 12:33:05 -0400
> message:
>   Don't reuse previous Message-id when resending.
> modified:
>   lisp/ChangeLog
>   lisp/mail/rmail.el

> === modified file 'lisp/ChangeLog'
> --- a/lisp/ChangeLog	2011-06-23 13:03:04 +0000
> +++ b/lisp/ChangeLog	2011-06-23 16:33:05 +0000
> @@ -1,3 +1,7 @@
> +2011-06-23  Richard Stallman  <rms@gnu.org>
> +
> +	* mail/rmail.el (rmail-retry-ignored-headers): Add message-id.
> +
>  2011-06-23  Michael Albinus  <michael.albinus@gmx.de>
 
>  	* net/tramp-sh.el (tramp-method-out-of-band-p): Check, whether

> === modified file 'lisp/mail/rmail.el'
> --- a/lisp/mail/rmail.el	2011-06-23 08:58:45 +0000
> +++ b/lisp/mail/rmail.el	2011-06-23 16:33:05 +0000
> @@ -349,7 +349,7 @@
>    :group 'rmail-headers)
 
>  ;;;###autoload
> -(defcustom rmail-retry-ignored-headers (purecopy "^x-authentication-warning:\\|^x-detected-operating-system:\\|^x-spam[-a-z]*:\\|content-type:\\|content-transfer-encoding:\\|mime-version:")
> +(defcustom rmail-retry-ignored-headers (purecopy "^x-authentication-warning:\\|^x-detected-operating-system:\\|^x-spam[-a-z]*:\\|content-type:\\|content-transfer-encoding:\\|mime-version:\\|message-id:")
>    "Headers that should be stripped when retrying a failed message."
>    :type '(choice regexp (const nil :tag "None"))
>    :group 'rmail-headers


> _______________________________________________
> Emacs-diffs mailing list
> Emacs-diffs@gnu.org
> https://lists.gnu.org/mailman/listinfo/emacs-diffs

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

[Glenn Morris]

Stefan Monnier wrote:

> Why?

>>   Don't reuse previous Message-id when resending.

To spell it out more explicitly, this change appears to be incorrect.

http://tools.ietf.org/html/rfc2822

3.6.6. Resent fields

Resent fields SHOULD be added to any message that is reintroduced by a
user into the transport system. [...] No other fields in the message are
changed when resent fields are added.
[...]
resent-msg-id   =       "Resent-Message-ID:" msg-id CRLF
[...]
Resent fields are used to identify a message as having been reintroduced
into the transport system by a user. The purpose of using resent fields
is to have the message appear to the final recipient as if it were sent
directly by the original sender, with all of the original fields
remaining the same.
[...]
Note: Reintroducing a message into the transport system and using
resent fields is a different operation from "forwarding".
[...]
Note: When replying to a resent message, replies behave just as they
would with any other message, using the original "From:",
"Reply-To:", "Message-ID:", and other fields.
[...]
The "Resent-Message-ID:" field provides a unique identifier for the
resent message.

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

[Richard Stallman]

This is not really for "resend", it is for `rmail-retry-failure'.
Sorry about that.

I fixed this because sending the message again with the same
Message-ID caused confusion in another program that did processing of
mail.  It did not expect to get two messages on different dates with
the same Message-ID.

Unfortunately, that was about a year ago, so I don't recall any
details.

Using a new Message-ID can't do any harm.  It isn't wrong.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org, www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use free telephony http://directory.fsf.org/category/tel/

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

[Stephen J. Turnbull]

Richard Stallman writes:

 > Using a new Message-ID can't do any harm.

Maybe not to you, but in case of partial failure it will create a new
subthread, confusing participants in the original thread.

 > It isn't wrong.

Sorry, Richard, that is not yours to decide.  This change is OK for
your personal version of Emacs, but in general it is the sender's
decision, not the implementer's.  From RFC 5322:

      In all cases, it is the meaning that the sender of the message
      wishes to convey (i.e., whether this is the same message or a
      different message) that determines whether or not the
      "Message-ID:" field changes, not any particular syntactic
      difference that appears (or does not appear) in the message.

For *most* users *most* of the time, a "retried" message should have
the same Message-ID (eg, if only some destinations failed).
Defaulting to same Message-ID is very safe as long as the content
doesn't change.  On the one hand, users are very unlikely to perceive
them as "different."  On the other, getting multiple copies of a
message with the same Message-ID is a common occurrance, and any
program dealing with Message-IDs should be able to deal with it.  But
defaulting to different Message-IDs does cause harm in the case of
partial retries.

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

[Richard Stallman]

     > Using a new Message-ID can't do any harm.

    Maybe not to you, but in case of partial failure it will create a new
    subthread, confusing participants in the original thread.

I cannot follow that concretely.  However, it is perfectly normal to
write multiple responses to a single incoming message.  Retrying the
first response with a new Message-ID is a special case of that, so it
can't be wrong.  I am confident that any programs designed to keep
track of threads do something reasonable in this case.

     > It isn't wrong.

    Sorry, Richard, that is not yours to decide.

It is not up to you what the GNU Project can decide.

    From RFC 5322:

The RFC forgot to send an army with you, so it cannot expect to be
obeyed.

In the GNU Project, we do not obey standards -- we consider them, then
DTRT.  Often TRT is to do what the standard says.  Sometimes TRT is
something else.  For instance, GCC doesn't obey the ANSI C spec unless
you use --pedantic.  Bash does not obey the POSIX spec unless you set
POSIXLY_CORRECT.

You can make arguments about what is TRT, but they can only succeed if
they do not presume the RFC has authority.

    in general it is the sender's
    decision, not the implementer's

I agree, and that's how it is.  This variable specifies the way the
mail buffer is initialized.  The user has ultimate control.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org, www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use free telephony http://directory.fsf.org/category/tel/

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

[Uday S Reddy]

On 6/27/2011 5:28 PM, Richard Stallman wrote:

>
> I cannot follow that concretely.  However, it is perfectly normal to
> write multiple responses to a single incoming message.  Retrying the
> first response with a new Message-ID is a special case of that, so it
> can't be wrong.  I am confident that any programs designed to keep
> track of threads do something reasonable in this case.

Something "reasonable" can be done.  But I don't think it is ideal.

If there are two copies of the same message in the mail folder with 
different Message-ID's, then some responses would get threaded under one 
copy and the others under the other copy, causing confusion.  If the 
user happens to delete one of the copies, since it is logically a 
duplicate, then the responses threaded under it would get messed up.

On the other hand, I know from experience that dealing with duplicate 
copies of messages is surprisingly tricky.  So, I can sympathize with 
the problems of mail client developers, and not being able to handle 
duplicate copies with different dates.

Hopefully, this doesn't happen too often.

Cheers,
Uday

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

[Stephen J. Turnbull]

Richard Stallman writes:

 > I cannot follow that concretely.

Maybe you should have asked about that, then.  It's important.

 > However, it is perfectly normal to write multiple responses to a
 > single incoming message.

Sure.  I haven't used RMail in decades, but I seem to recall that
there are several ways to do that if your intent is to reply with
different content each time.  But retrying a failed message isn't one
of them; that's a different use case, and typically in my experience
involves not changing the message body at all.

 > Retrying the first response with a new Message-ID is a special case
 > of that, so it can't be wrong.

In general, however, it is not conforming to the RFC, which specifies
that if the sender considers the content of the message to be the
same, the Message-ID should be the same.  You encountered software
that cannot handle two messages with the same ID, so you want this.
Fully conforming, as long as you only do this for yourself.

That, however, is a very rare use case.  (At least, I've never heard
of it before.)  Most users will expect the semantics that two messages
with different Message-IDs have different content, and that is *why*
the RFC is specified as it is.

If what you mean is that you edit the message so that it has somewhat
different content, then indeed I expect it should in most cases have a
different Message-ID (although that's up to the sender).  However, I
wouldn't consider that a typical retry -- almost all of my retries
simply involve fixing an address typo and resending content as is.  Do
you have a reason for frequently doing something else, I mean one that
would apply to enough users to justify the change in default?

 > I am confident that any programs designed to keep track of threads
 > do something reasonable in this case.

Your confidence has no bearing on correctness, unfortunately.  You're
wrong.  This introduces an ambiguity that can only be handled by
analyzing the content of the message and attempting to guess whether
the sender thinks of this as a new message.  That's a hard problem.

What threading MUAs do in practice is to punt.  They see different
Message-IDs and they split the thread, although none of the
correspondents want that since they all perceive the messages as being
a single message that arrived multiple times (usually at different
places; it's even more annoying if it arrives twice in the same
mailbox with different Message-IDs).

There is no mechanical way to merge threads once split; you have to
persuade all of the participants to abandon one thread and concentrate
on the other, which is pretty chancy at best.  In practice it's common
for latecomers to respond to the "wrong" subthread because it seems to
just have left obvious issues unresolved.

 >      > It isn't wrong.
 > 
 >     Sorry, Richard, that is not yours to decide.
 > 
 > It is not up to you what the GNU Project can decide.

When put that way, no, of course not.  What I meant is, "feel free to
disagree with the rest of the world, and be aware that those you need
to cooperate with to use email will consider your decision *wrong*."

 > In the GNU Project, we do not obey standards -- we consider them, then
 > DTRT.

Yeah, I know.  I'm not suggesting that you change that, just this
default.

 > You can make arguments about what is TRT, but they can only succeed if
 > they do not presume the RFC has authority.

"Authority"?  *This* RFC has been best practice for the largest
electronic community in existence for longer than Emacs has been in
existence.  Call that "authority" if you like, but I prefer to think
of it as "listening to others' experience."  Emacs is only hurting
itself if it defaults to semantics which few users will expect, even
if it's only occasionally noticable.

 >     in general it is the sender's decision, not the implementer's
 > 
 > I agree, and that's how it is.  This variable specifies the way the
 > mail buffer is initialized.  The user has ultimate control.

Control is only useful if the user is informed of the choice they need
to make, and have a convenient way to implement it.  For most users
leaving things as they were does the right thing without them thinking
about it at all, and that's a good thing.  On the other hand, with the
default as you specify it, the consequences are unobvious, and
recovery is impossible once the message is sent, and difficult at best
during the composition stage.

In other words, the default you specified is going to cause naive
users to do themselves inadvertant harm.  You know what you are doing
and why, they don't.  So you should customize that variable for
yourself and let Emacs have a safe default.

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

[Richard Stallman]

You are wasting your time trying to argue from authority.  But you're
not wasting mine, because I'm not going to take time to study your
message to prise out any parts of the argument that don't depend on
claiming RFCs have authority.  The onus is on you.


-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org, www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use free telephony http://directory.fsf.org/category/tel/

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

[Stephen J. Turnbull]

Richard Stallman writes:

 > You are wasting your time trying to argue from authority.

Please, stop using offensive language.  It clouds your mind. ;-)
"Authority" has no connection to this issue.

*None* of my arguments depend on "authority".  *You explicitly agreed
with the principal statement of the RFC* ("the sender's intention
rules").  How can there be any issue of "authority" when in fact we
agree on the right thing at that level?  The RFC does not go beyond
that (except to explicitly disclaim that analysis of content can be
sufficient to determine sender's intent).

The point is that, contrary to your claim, the behavior you installed
is *not* harmless, it does occasional, but specific, predictable, and
widespread, harm to the users of threading MUAs.  Stefan referred to
it, I've described it, Uday has described it.  It's real.  It is not
"dealt with reasonably" by existing MUAs, and cannot be.

OTOH, you have cited a past inconvenience involving only you and a
certain program, whose details you don't even remember.  I'm sure it
was a real issue, but hardly a justification for changing this default
IMO.

I think there is good reason here for you to reconsider.

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

[Daniel Colascione]

[-- Attachment #1: Type: text/plain, Size: 635 bytes --]

On 6/27/2011 4:03 PM, Richard Stallman wrote:
> You are wasting your time trying to argue from authority.  But you're
> not wasting mine, because I'm not going to take time to study your
> message to prise out any parts of the argument that don't depend on
> claiming RFCs have authority.  The onus is on you.

You should reconsider that decision.  Stephen's message cogently
explains _exactly_ why the behavior specified in the RFC is also the
right thing to do. He's provided plenty of evidence that Message-Id
reuse adversely affects MUA threading. The burden of demonstrating
otherwise is now yours to show otherwise.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 258 bytes --]

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

[Eli Zaretskii]

> Date: Mon, 27 Jun 2011 18:45:06 -0700
> From: Daniel Colascione <dan.colascione@gmail.com>
> Cc: "Stephen J. Turnbull" <stephen@xemacs.org>, monnier@iro.umontreal.ca,
> 	emacs-devel@gnu.org
> 
> You should reconsider that decision.  Stephen's message cogently
> explains _exactly_ why the behavior specified in the RFC is also the
> right thing to do. He's provided plenty of evidence that Message-Id
> reuse adversely affects MUA threading. The burden of demonstrating
> otherwise is now yours to show otherwise.

Who's talking about _reuse_?  The use case is that the original
message didn't get sent.  There's no reuse; there's a single message
with an ID that never saw the light of day before.

Now, can we _please_ stop this silly thread??

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

[Uday S Reddy]

On 6/28/2011 3:56 AM, Eli Zaretskii wrote:

> Who's talking about _reuse_?  The use case is that the original
> message didn't get sent.  There's no reuse; there's a single message
> with an ID that never saw the light of day before.

If the original message didn't get sent, there is no issue at all. 
Richard's problem was that it got partially sent to some of the 
recipients.  These recipients then received a second (retried) copy of 
the same message at a later date and got "confused".  Richard is trying 
to help these confused mail clients.  That is the use case.

By the way, if my mail client got confused in that way, I would regard 
it as a bug and fix it, not force the senders to change their software.

> Now, can we _please_ stop this silly thread??

Multiple copies of messages floating around the cyberspace with 
different message ID's is a form of pollution.  The gnu servers are 
partly responsible for this.  The gnu newsgroups and mailing lists are 
full of broken threads as a result.  Richard's decision makes the 
problem slightly worse.  But it has been pretty bad already.

Cheers,
Uday

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

[Richard Stallman]

    You should reconsider that decision.  Stephen's message cogently
    explains _exactly_ why the behavior specified in the RFC is also the
    right thing to do.

I don't know what it explains, and I am not going to try to find out.
I am not going to read a long, arrogant and hostile message, some of
which is clearly based on false premises, to see if any parts of it
might be valid.

If he thinks I am wrong, and wants me to pay attention to his opinion,
he should present it to me in a way that isn't hostile and doesn't
waste my time.  And he should recognize that Emacs maintenance decisions
do not require his approval.


-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org, www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use free telephony http://directory.fsf.org/category/tel/

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

[Richard Stallman]

    If there are two copies of the same message in the mail folder with 
    different Message-ID's, then some responses would get threaded under one 
    copy and the others under the other copy, causing confusion.

If these two messages are in the same thread to start with -- for
instance, if they are replies to the same message -- won't the
responses to them also be part of that thread?

However, there is also the case where the two messages are not replies.
In that case, there is nothing to tie them together.  That is not good.


-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org, www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use free telephony http://directory.fsf.org/category/tel/

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

[Eli Zaretskii]

> From: Uday S Reddy <usr.vm.rocks@gmail.com>
> 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.  For example, consider the
possibility that a message bounced because some overly-protective
server detected some words or phrases considered profanity.  (I once
got my message bounced just by using "XXX" somewhere.)  In that case,
the user will certainly edit the body before resending.

> These recipients then received a second (retried) copy of 
> the same message at a later date and got "confused".  Richard is trying 
> to help these confused mail clients.  That is the use case.

Even if you are right (and you aren't, see above), this is not about
_reusing_ the Message-id.  It is about using a _different_ Message-id.

> By the way, if my mail client got confused in that way, I would regard 
> it as a bug and fix it, not force the senders to change their software.

Richard didn't say "mail client", he said "another program".  If you
really are interested in the details, you should ask, not assume.

> Richard's decision makes the problem slightly worse.

I disagree, see the docs excerpts above.  I submit that you interpret
the RFC too literally, where the RFC itself gives the sender a lot of
leeway in this matter:

   The "Message-ID:" field provides a unique message identifier that
   refers to a particular version of a particular message.
   ...
   A message identifier pertains to exactly one version of a
   particular message; subsequent revisions to the message each
   receive new message identifiers.
   ...
   In all cases, it is the meaning that the sender of the message
   wishes to convey (i.e., whether this is the same message or a
   different message) that determines whether or not the "Message-ID:"
   field changes

There's no rigorous definition in the RFC what exactly constitutes a
"new version" of a message.  Nor could there be, because "it is the
_meaning_ that the sender wishes to convey" that determines that.

So your interpretation is only one possibility, but not the only one.
And that's even before we discuss the case that the message (either
its headers or body) are actually edited, e.g. to add something like
"resending because the original bounced", which is clearly within the
use case being discussed.

Bottom line, this is hardly a reason good enough to start holy wars
about adherence to standards.

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

[Richard Riley]

Richard Stallman <rms@gnu.org> writes:

>     You should reconsider that decision.  Stephen's message cogently
>     explains _exactly_ why the behavior specified in the RFC is also the
>     right thing to do.
>
> I don't know what it explains, and I am not going to try to find out.
> I am not going to read a long, arrogant and hostile message, some of
> which is clearly based on false premises, to see if any parts of it
> might be valid.
>
> If he thinks I am wrong, and wants me to pay attention to his opinion,
> he should present it to me in a way that isn't hostile and doesn't
> waste my time.  And he should recognize that Emacs maintenance decisions
> do not require his approval.

Are messages being dropped from this thread? I saw no replies from
Stephen that were rude or hostile, indeed in the circumstances polite
and informative - you might learn something from them.

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

[Richard Stallman]

    Are messages being dropped from this thread? I saw no replies from
    Stephen that were rude or hostile, indeed in the circumstances polite
    and informative - you might learn something from them.

You may have not noticed the aggression in those messages.  If there
is some valid point in them, I don't choose to do the work, or suffer
the aggression, to extract it from the rest.  If it is important,
someone else will say it without hostility.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org, www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use free telephony http://directory.fsf.org/category/tel/

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

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Uday S Reddy <usr.vm.rocks@gmail.com>
>> 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

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

[Stefan Monnier]

> This is not really for "resend", it is for `rmail-retry-failure'.

So it puts you in a new edit buffer before actually sending the message?
I guess it's OK then.  I often suffer from multiple copies of messages
where something somewhere changed the Message-ID along the way, so
I don't like this change much, but it's not worth fighting about,


        Stefan