Change in rmail-reply

Change in rmail-reply

[Richard M Stallman]

    +	* mail/rmail.el (rmail-reply): Don't include Resent-To and Resent-Cc in
    +	replies.  (Bug#512)

Why do you think this change is correct in general?
It gives the desired results in this particular case,
but in general it seems to be wrong.

Re: Change in rmail-reply

[Glenn Morris]

Richard M Stallman wrote:

>     +	* mail/rmail.el (rmail-reply): Don't include Resent-To and Resent-Cc in
>     +	replies.  (Bug#512)
>
> Why do you think this change is correct in general?
> It gives the desired results in this particular case,
> but in general it seems to be wrong.

This was discussed:

emacs-devel
Sun, 29 June 2008
Re: postmaster@bogus.example.com: Delivery Notification: Delivery has failed
From: Sven Joachim

(the actual subject address is hidden in the web archive)

http://lists.gnu.org/archive/html/emacs-devel/2008-06/msg01960.html

[my emphasis below]
  
  It was in the "Resent-To" field, and rmail-reply includes that in the
  list of addresses for the reply.  That does not seem to comply to RFC
  2822 which states:
  
     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. Each set of resent
     fields correspond to a particular resending event. That is, if a
     message is resent multiple times, each set of resent fields gives
     identifying information for each individual time. Resent fields are
     strictly informational. They MUST NOT be used in the normal
                             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
     processing of replies or other such automatic actions on messages.
     ^^^^^^^^^^^^^^^^^^^^^  

  I think Rmail should be fixed to not send replies to Resent-* addresses.

[...] it needs to be updated: the RFC is pretty clear.

Re: Change in rmail-reply

[Richard M Stallman]

The RFC is clear, but it seems to be clearly wrong.  If John Doe sends
a message to you, and you resend it to me, and I do "reply to all", it
seems clear that my reply should by default go to you.

And if you resent it to emacs-devel as well as to me, it seems clear
that "reply to all" should include emacs-devel by default.

Can anyone present an argument in support of what the RFC says?

Re: Change in rmail-reply

[Don Armstrong]

On Tue, 27 Jan 2009, Richard M Stallman wrote:
> The RFC is clear, but it seems to be clearly wrong. If John Doe
> sends a message to you, and you resend it to me, and I do "reply to
> all", it seems clear that my reply should by default go to you.

Resent-To: shouldn't be set in such a case; that's forwarding, and
should end up with entirely new From/To headers.

> And if you resent it to emacs-devel as well as to me, it seems clear
> that "reply to all" should include emacs-devel by default.
> 
> Can anyone present an argument in support of what the RFC says?

Resent-To: fields are only there to indicate when a message has been
reinserted into the mail delivery chain by someone.


Don Armstrong

-- 
A citizen of America will cross the ocean to fight for democracy, but
won't cross the street to vote in a national election.
 -- Bill Vaughan

http://www.donarmstrong.com              http://rzlab.ucr.edu

Re: Change in rmail-reply

[Stefan Monnier]

> Resent-To: fields are only there to indicate when a message has been
> reinserted into the mail delivery chain by someone.

Yes.  And in many cases, those fields aren't even added.
They're about as useful as the "Received:" headers.


        Stefan

Re: Change in rmail-reply

[Richard M Stallman]

    > The RFC is clear, but it seems to be clearly wrong. If John Doe
    > sends a message to you, and you resend it to me, and I do "reply to
    > all", it seems clear that my reply should by default go to you.

    Resent-To: shouldn't be set in such a case; that's forwarding, and
    should end up with entirely new From/To headers.

You seem to assume a distinction between "forwarding" and "resending".
Would you please explain it?

    Resent-To: fields are only there to indicate when a message has been
    reinserted into the mail delivery chain by someone.

When you resend John Doe's message to me, doesn't that mean it has
been "reinserted into the mail delivery chain" by you?  I seems that
way to me.

Re: Change in rmail-reply

[Harald Hanche-Olsen]

+ Richard M Stallman <rms@gnu.org>:

>     > The RFC is clear, but it seems to be clearly wrong. If John Doe
>     > sends a message to you, and you resend it to me, and I do "reply to
>     > all", it seems clear that my reply should by default go to you.
> 
>     Resent-To: shouldn't be set in such a case; that's forwarding, and
>     should end up with entirely new From/To headers.
> 
> You seem to assume a distinction between "forwarding" and "resending".
> Would you please explain it?
> 
>     Resent-To: fields are only there to indicate when a message has been
>     reinserted into the mail delivery chain by someone.
> 
> When you resend John Doe's message to me, doesn't that mean it has
> been "reinserted into the mail delivery chain" by you?  I seems that
> way to me.

Technically yes, but RFC2822 explains it thus:

   Note: Reintroducing a message into the transport system and using
   resent fields is a different operation from "forwarding".
   "Forwarding" has two meanings: One sense of forwarding is that a mail
   reading program can be told by a user to forward a copy of a message
   to another person, making the forwarded message the body of the new
   message.  A forwarded message in this sense does not appear to have
   come from the original sender, but is an entirely new message from
   the forwarder of the message.  On the other hand, forwarding is also
   used to mean when a mail transport program gets a message and
   forwards it on to a different destination for final delivery.  Resent
   header fields are not intended for use with either type of
   forwarding.

- Harald

Re: Change in rmail-reply

[Richard M Stallman]

       Note: Reintroducing a message into the transport system and using
       resent fields is a different operation from "forwarding".
       "Forwarding" has two meanings: One sense of forwarding is that a mail
       reading program can be told by a user to forward a copy of a message
       to another person, making the forwarded message the body of the new
       message.  A forwarded message in this sense does not appear to have
       come from the original sender, but is an entirely new message from
       the forwarder of the message.

Now I understand how these terms are being used.  Forwarding and
resending do similar jobs, but package the message differently.

The RFC is clear, but it seems to be clearly wrong.  If John Doe sends
a message to you, and you resend it to me, and I do "reply to all", it
seems clear that my reply should by default go to and to all the
other people you resent it to -- as well as to the sender and recipients
of the original message.

Can anyone present an argument in support of what the RFC says?

Someone else wrote:

    The distinction is the difference between "I'd like you to see this
    mail" and "this mail was misdirected to me". [If you've used mutt,
    it's the difference between forward and bounce.]

I can see why, in the misdirected case, you would prefer to use resend.
I have not seen any statement previously that resend is only intended
for that case.  Is this the stated purpose of resend?

But if that is the motive for using resend, it seems to support
the conclusion that replies should go to the other people
to whom you resent the message.

Re: Change in rmail-reply

[Stefan Monnier]

> Can anyone present an argument in support of what the RFC says?

I'm not sure exactly what is the purpose of this discussion: all MUAs
other than Rmail (AFAIK) ignore "resent-(to|cc)" when replying to
a message, which is why systems like debbugs don't work harder to hide
the intermediate email address and leave it in "resent-to".

So, I don't think it's worthwhile to try and figure out what the RFC
says, meant to say, or should say.


        Stefan

Re: Change in rmail-reply

[Stephen J. Turnbull]

Richard M Stallman writes:

 > The RFC is clear, but it seems to be clearly wrong.  If John Doe sends
 > a message to you, and you resend it to me, and I do "reply to all", it
 > seems clear that my reply should by default go to [you]

If the resender wishes to indicate interest in the conversation, they
can do this in a number of ways, including adding themselves as a CC,
specifying a Reply-To header, or forwarding the message (ie,
encapsulating the original text in a new message with themselves in
the From header).

 > and to all the other people you resent it to -- as well as to the
 > sender and recipients of the original message.
 > 
 > Can anyone present an argument in support of what the RFC says?

In my experience the most frequent users of Resent-* headers are not
human agents, but daemons.  I see no good to come of automatically
adding their addresses to the reply-to list.

Re: Change in rmail-reply

[Richard M Stallman]

     > The RFC is clear, but it seems to be clearly wrong.  If John Doe sends
     > a message to you, and you resend it to me, and I do "reply to all", it
     > seems clear that my reply should by default go to [you]

    If the resender wishes to indicate interest in the conversation, they
    can do this in a number of ways, including adding themselves as a CC,
    specifying a Reply-To header, or forwarding the message (ie,
    encapsulating the original text in a new message with themselves in
    the From header).

I realize now that the resender is not a real issue.  He is most
likely one of the recipients of the original message, or reached via
them, so sending a response there will reach him.

The real issue is the other people to whom the message was resent.
If he resends the message to rms@gnu.org and stephen@xemacs.org,
and I reply, shouldn't my reply go to you?

Adding the other recipients to the CC list may be difficult.  With
rmail-resend, the user does not edit the message.  The idea is that
all he needs to do is specify where to resend to, in the minibuffer,
and then it goes there.  Isn't that what resending is for?

As for fowarding, that is no substitute, since the new header does not
include the sender or other recipients of the original message.  When
you want to exclude them, forwarding is suitable.  Otherwise, it isn't.

If resending as a feature is designed for demons to send to
intermediate addresses, and not for humans to use, what does that
imply about rmail-resend?

Should we delete the rmail-resend command?  Make it warn "This command
has counterintuitive results, since replies won't go to the other
recipients you resend to"?  Make it add those recipients to the CC
list as well as putting them in Resent-to?

Re: Change in rmail-reply

[Stephen J. Turnbull]

Richard M Stallman writes:

 > The real issue is the other people to whom the message was resent.
 > If he resends the message to rms@gnu.org and stephen@xemacs.org,
 > and I reply, shouldn't my reply go to you?

That depends on the content of the message and his intent.  I *know*
that in my own usage of reinjecting messages into the system there is
a wide variety of cases.

 > Adding the other recipients to the CC list may be difficult.

That's a different issue, and how to address it depends on the needs
and expectations of Rmail users.

 > With rmail-resend, the user does not edit the message.  The idea is
 > that all he needs to do is specify where to resend to, in the
 > minibuffer, and then it goes there.  Isn't that what resending is
 > for?

I don't know; ask the authors/user of Rmail!  What I use resend for is
when I'm moderating a mailing list or something like that.  If I have
interest in the topic, I'm probably subscribed to the mailing list; if
not I don't want to be included in replies for sure.

 > As for fowarding, that is no substitute, since the new header does not
 > include the sender or other recipients of the original message.  When
 > you want to exclude them, forwarding is suitable.  Otherwise, it isn't.

That's an issue with your MUA, if that is a common use case for you.

It is not a common use case for me.  For example, I often forward (as
a new message) messages from emacs-devel to individual XEmacs
developers, and occasionally to the xemacs-beta list as an
informational matter.  Those folks know where to find y'all if they
want to, emacs-devel has easy-to-find archives, and often the ensuing
discussion (if any) is very XEmacs-specific.  I do not want to pollute
emacs-devel with off-topic conversations, so forwarding is appropriate.

In the less frequent case where I do want to widen the conversation, I
typically want to comment on the message I'm sending as well.  In that
case a wide reply, adding the participants I think are appropriate to
Cc or To is my normal behavior.  Very rarely I will have two mailing
lists in such a post; in those cases (except when I'm under the
influence of mind- altering substances or my evil twin personality) I
invariably use Reply-To to narrow the conversion's address list
dramatically.

I'm not claiming that your use case(s) is nonexistent or unimportant,
but I think this illustrates a wide variety of use cases where it
would be redundant or annoying if addresses were pulled from Resent-*
headers willy-nilly.

 > If resending as a feature is designed for demons to send to
 > intermediate addresses, and not for humans to use, what does that
 > imply about rmail-resend?

I didn't say Resent-* headers were designed for daemons, I said in my
experience by far the most frequent use is by daemons.  However, I use
them implicitly (ie, via a resend command) myself on a once-a-month
basis, on the occasions where a message that should go to a list gets
shunted.  On those occasions I never want replies directed to me.

 > Should we delete the rmail-resend command?

No.  Better to rename it to something like rmail-bounce.  It is useful
as-is to humans acting as mail administrators.

 > Make it warn "This command has counterintuitive results, since
 > replies won't go to the other recipients you resend to"?

If you don't rename the command, probably it should be documented.
I wouldn't say "counterintuitive", I would say that the resent-to
recipients will be treated like Bcc, ie, invisible to MUAs' reply
facility (and most humans).

 > Make it add those recipients to the CC list as well as putting them
 > in Resent-to?

No.  That's redundant and its desirability is rather uncertain.  A
better approach would be to provide more flexible ways to pull
addresses from various places and add them to the recipient lists.

Re: Change in rmail-reply

[Richard M Stallman]

     > As for fowarding, that is no substitute, since the new header does not
     > include the sender or other recipients of the original message.  When
     > you want to exclude them, forwarding is suitable.  Otherwise, it isn't.

    That's an issue with your MUA, if that is a common use case for you.

I do not follow.  What issue about the MUA are you raising?

     > Should we delete the rmail-resend command?

    No.  Better to rename it to something like rmail-bounce.

"Bounce" in the context of mail usually indicates report that a
message failed to reach a recipient.  Does this case have anything to
do with such a failure?  If not, what's the reason to suggest
using that word?

It occurs to me that maybe there should be two resend commands:
one which lets you edit the message and one which doesn't.
The former would be new.  It could insert CC commands
with the resend recipients, so you can either keep them or
delete them.

Re: Change in rmail-reply

[Chetan Pandya]

From: Richard M Stallman <rms@gnu.org>


    > As for fowarding, that is no substitute, since the new header does not
     > include the sender or other recipients of the original message.  When
     > you want to exclude them, forwarding is suitable.  Otherwise, it isn't.

    That's an issue with your MUA, if that is a common use case for you.

  I do not follow.  What issue about the MUA are you raising?

     > Should we delete the rmail-resend command?

    No.  Better to rename it to something like rmail-bounce.

  "Bounce" in the context of mail usually indicates report that a
  message failed to reach a recipient.  Does this case have anything to
  do with such a failure?  If not, what's the reason to suggest
  using that word?

  It occurs to me that maybe there should be two resend commands:
  one which lets you edit the message and one which doesn't.
  The former would be new.  It could insert CC commands
  with the resend recipients, so you can either keep them or
   delete them.

I agree that bounce is also likely to be confusing, since the intent seems to use 
it on a message that has already bounced (non-delivery). 

Would it not make sense to use a different command when the message is edited?
Given all the confusion regarding resend, how about using it only in the case when 
only the recipient change (Resend-To and Resend-Cc) as per the RFC. 
When there is no change in the message content (such as reminders), it could still 
be sent as a new message, just like any other message that is edited and sent.

Chetan

Re: Change in rmail-reply

[Chetan Pandya]

One thing I don't like about this command is the potential for misuse - unless this is one of the intended uses.
The problem is that the recipient of the message may have no idea that the message is not really received 
from what it claims to be, if the recipient MUA does not look at the resend headers.  This might look like 
deception. Granted it is already possible to do it by other means, but the question is whether it should be 
made easier to do so.

Re: Change in rmail-reply

[Jason Rumney]

Chetan Pandya wrote:
> One thing I don't like about this command is the potential for misuse - unless this is one of the intended uses.
> The problem is that the recipient of the message may have no idea that the message is not really received 
> from what it claims to be, if the recipient MUA does not look at the resend headers.  This might look like 
> deception. Granted it is already possible to do it by other means, but the question is whether it should be 
> made easier to do so.
>   

If the intention is to deceive, then it is trivially easy to forge email 
headers, especially in an environment as configurable as Emacs. The 
resend command is very useful to a small minority of users who deal with 
mailing list moderation or catch-all mailboxes and want to forward mail 
in a way that keeps the original headers intact. The feature is provided 
by other mail clients, either as standard or as an optional extension, 
so its inclusion in rmail is not unique.

Re: Change in rmail-reply

[Chetan Pandya]

Jason Rumney <jasonr@gnu.org> wrote:


> Chetan Pandya wrote:

>> One thing I don't like about this command is the potential for misuse - unless this is one of the intended uses.
>> The problem is that the recipient of the message may have no idea that the message is not really received from what it claims to be, if the recipient MUA does not look at the resend headers.  This might look like deception. Granted it is already possible to do it by other means, but the question is whether it should be made easier to do so.
>>  

>If the intention is to deceive, then it is trivially easy to forge email headers, especially in an environment as configurable as Emacs. The resend command is very useful to a small minority of users who deal with mailing list moderation or catch-all mailboxes and want to forward mail in a way that keeps the original headers intact. The feature is provided by other mail clients, either as standard or as an optional extension, so its inclusion in rmail is not unique.

The usefulness in some situations is not disputed.  However, the fact still remains that as it is, it has a limited usefulness for ordinary users. Like other commands that may be confusing to users, it could be disabled by default, unless explicitly enabled by the user. Within emacs itself, mh-e also seems to provide the feature, so it certainly isn't unique. Irrespective of what is done on the send side, it might make sense to show resent-from, especially if it is different from from field. Similar situation exists wrt "sender:", but in that case it is not conditional. Of course, it could be argued that it is configurable, but the default configuration should be not be a cause for confusion to users who may not be familiar with all the issues, IMO.

Chetan

Re: Change in rmail-reply

[Stephen J. Turnbull]

Chetan Pandya writes:
 > Jason Rumney <jasonr@gnu.org> wrote:
 > > Chetan Pandya wrote:
 > 
 > >> One thing I don't like about this command is the potential for
 > >> misuse - unless this is one of the intended uses.
 > >> The problem is that the recipient of the message may have no
 > >> idea that the message is not really received from what it claims
 > >> to be,

That is in fact the intent of the Resent-* headers.  Personally, I
like the intuition that "the RESEND command uses RESENT-* headers to
avoid looking like a FORWARD".

Obviously you and Richard have a different intuition, based on the
fact that you don't use resend for its designed purpose, but rather
because it saves keystrokes compared to forward (in his case, anyway).

 > Like other commands that may be confusing to users, it could be
 > disabled by default, unless explicitly enabled by the user.

I think it would be better to enhance the forward command (or split it
into "forward" and "quick-forward") so that there is less temptation
to use the resend command as a low- effort forward.  You could remove
the key-binding for resend; that should be sufficient discouragement.

 > Irrespective of what is done on the send side, it might make sense
 > to show resent-from, especially if it is different from from field.

Resent-From is *almost always* different from From.  If it is expected
to be of interest to the recipient, then the sender should not be
using resend in the first place; they should use forward.  On the
downside of your suggestion, do you really want to see that
<mailman-bounces+chetan-pandya@gnu.org> resent the post for every
single post to emacs-devel that you receive?  That's what your
suggestion would cause.

Re: Change in rmail-reply

[Chetan Pandya]

From: Stephen J. Turnbull <stephen@xemacs.org>


>Chetan Pandya writes:
>> Jason Rumney <jasonr@gnu.org> wrote:
>> > Chetan Pandya wrote:
>> 
>> >> One thing I don't like about this command is the potential for
>> >> misuse - unless this is one of the intended uses.
>> >> The problem is that the recipient of the message may have no
>> >> idea that the message is not really received from what it claims
>> >> to be,

>That is in fact the intent of the Resent-* headers.  Personally, I
>like the intuition that "the RESEND command uses RESENT-* headers to
>avoid looking like a FORWARD".

>Obviously you and Richard have a different intuition, based on the
>fact that you don't use resend for its designed purpose, but rather
>because it saves keystrokes compared to forward (in his case, anyway).

Actually I don't use resend at all. The only examples I have seen so far deal
with administration of mailing lists. However, if something works for the 
intended use, but there are instances where it can be misused, it makes 
sense to provide some way to deal with it.

>> Like other commands that may be confusing to users, it could be
>> disabled by default, unless explicitly enabled by the user.

>I think it would be better to enhance the forward command (or split it
>into "forward" and "quick-forward") so that there is less temptation
>to use the resend command as a low- effort forward.  You could remove
>the key-binding for resend; that should be sufficient discouragement.

These are different approaches to preventing users from using the 
command unintentionally.  However, I like the idea of disabled command, 
so that the keybinding is still shown in C-h m, in case someone needs
it and is looking for.

>> Irrespective of what is done on the send side, it might make sense
>> to show resent-from, especially if it is different from from field.

>Resent-From is *almost always* different from From.  If it is expected
>to be of interest to the recipient, then the sender should not be
>using resend in the first place; they should use forward.  On the
>downside of your suggestion, do you really want to see that
><mailman-bounces+chetan-pandya@gnu.org> resent the post for every
>single post to emacs-devel that you receive?  That's what your
>suggestion would cause.

The Resent-From will likely be different from From: in the case of 
mailing list. However, there are instances where it can be same.
From the sender's point of view, the sender's identify if not important if 
"resend" is used knowingly. However, on the recipient side, it is a 
different story.  If I had a choice, I would be reading my mailing lists 
differently. However, to answer the question, yes, I would like to see 
the sender. Just because things are fine most of the time does not 
mean they will be the fields are useless, especially if there are 
bogus messages to deal with. 

-Chetan

Re: Change in rmail-reply

[Richard M Stallman]

    Obviously you and Richard have a different intuition, based on the
    fact that you don't use resend for its designed purpose, but rather
    because it saves keystrokes compared to forward (in his case, anyway).

I don't actually use it, and my thinking about it has nothing to do
with saving keystrokes.  The question I am thinking about is what
behavior for various commands would be useful and coherent.

Re: Change in rmail-reply

[Jason Rumney]

Richard M Stallman wrote:
>      > Should we delete the rmail-resend command?
>
>     No.  Better to rename it to something like rmail-bounce.
>
> "Bounce" in the context of mail usually indicates report that a
> message failed to reach a recipient.  Does this case have anything to
> do with such a failure?  If not, what's the reason to suggest
> using that word?
>   


The Thunderbird extension that provides this feature calls it "Redirect" 
in the menu.

Re: Change in rmail-reply

[Jason Rumney]

Richard M Stallman wrote:
> It occurs to me that maybe there should be two resend commands:
> one which lets you edit the message and one which doesn't.
> The former would be new.  It could insert CC commands
> with the resend recipients, so you can either keep them or
> delete them.
>   

If you want to edit the message and Cc the original recipents, then 
rmail-reply, adding the extra recipients to the To or Cc would be more 
appropriate. If you don't want to Cc the original recipients, then 
forward may be more appropriate, possibly with a Reply-To line that 
includes the original recipents and sender (perhaps that is a new 
function that could be provided).

Resend should be limited to non-edited messages only - if the message is 
edited, then it comes from you, not the original sender.

Re: Change in rmail-reply

[Richard M Stallman]

    If you want to edit the message and Cc the original recipents, then 
    rmail-reply, adding the extra recipients to the To or Cc would be more 
    appropriate.

Using reply would be totally inconvenient, since the point is to send the
same message.

    Resend should be limited to non-edited messages only - if the message is 
    edited, then it comes from you, not the original sender.

All else being equal, I agree; but it is hard to let people
edit the headers without also letting them edit the rest.

Re: Change in rmail-reply

[Stephen J. Turnbull]

Richard M Stallman writes:

 >      > As for fowarding, that is no substitute, since the new header does not
 >      > include the sender or other recipients of the original message.  When
 >      > you want to exclude them, forwarding is suitable.  Otherwise, it isn't.
 > 
 >     That's an issue with your MUA, if that is a common use case for you.
 > 
 > I do not follow.  What issue about the MUA are you raising?

The need for a rmail-resend variant which allows editing the headers,
as you describe below.  Personally, I would tend to add the feature to
the forward command instead, but thats a matter of style, not substance.

 >      > Should we delete the rmail-resend command?
 > 
 >     No.  Better to rename it to something like rmail-bounce.
 > 
 > "Bounce" in the context of mail usually indicates report that a
 > message failed to reach a recipient.  Does this case have anything to
 > do with such a failure?  If not, what's the reason to suggest
 > using that word?

The analogy is that physically, something that bounces doesn't
interact with the thing in bounced off of; it simply changes
direction, leaving both the bouncer and the bouncee otherwise
unchanged.  The failed-mail report originally was a special case of
this, with just enough additional information to identify it clearly
as a resend for the purpose of identifying an error.  Thus it is
called a "bounce".  The semantics have changed, but the name stuck.

 > It occurs to me that maybe there should be two resend commands:
 > one which lets you edit the message and one which doesn't.
 > The former would be new.  It could insert CC commands
 > with the resend recipients, so you can either keep them or
 > delete them.

As long as there is no parsing of Resent-* headers for addresses to
add to the recipient list, that would be fine.

Note that the semantics of mail for this purpose are still
problematic.  The original recipients may never know that the
conversation has been broadened in this way if you don't send the
forward (with the new headers) to them, too.  On the other hand, they
might not care, and be annoyed by the duplication.  It's not a big
hairy deal, of course, but these nuances apparently matter somewhat to
you.  To the extent that they do, you may wish to advocate changing
the channels where you want to use these features to use more
appropriate technology (usenet, web forum, etc).

Re: Change in rmail-reply

[Don Armstrong]

On Tue, 27 Jan 2009, Richard M Stallman wrote:
>     Resent-To: shouldn't be set in such a case; that's forwarding, and
>     should end up with entirely new From/To headers.
> 
> You seem to assume a distinction between "forwarding" and "resending".

I'm not assuming it; RFC 2822 makes the distinction.

> Would you please explain it?

The distinction is the difference between "I'd like you to see this
mail" and "this mail was misdirected to me". [If you've used mutt,
it's the difference between forward and bounce.]

>     Resent-To: fields are only there to indicate when a message has
>     been reinserted into the mail delivery chain by someone.
> 
> When you resend John Doe's message to me, doesn't that mean it has
> been "reinserted into the mail delivery chain" by you? I seems that
> way to me.

A message which has From: of the new sender and To: of the new
recipient is reinserted when you forward.


Don Armstrong

-- 
America was far better suited to be the World's Movie Star. The
world's tequila-addled pro-league bowler. The world's acerbic bi-polar
stand-up comedian. Anything but a somber and tedious nation of
socially responsible centurions.
 -- Bruce Sterling, _Distraction_ p122

http://www.donarmstrong.com              http://rzlab.ucr.edu