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

[Eli Zaretskii]

> 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.  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.