Errors-to: owner-drums@CS.UTK.EDU
Message-Id: <199509182315.TAA25193@CS.UTK.EDU>
To: drums@CS.UTK.EDU
From: "Roger Fajman" <RAF@CU.NIH.GOV>
Date:     Mon, 18 Sep 1995  19:13:28 EDT
Subject:  Re:  Resent- facility

> On Mon, 18 Sep 1995 21:54:57 +0200, Eric Thomas wrote:
> > On Tue, 19 Sep 1995 05:38:35 +1000 Robert Elz <kre@munnari.OZ.AU> said:
> > >I'm not sure about that. I am  coming to the opinion that Resent headers
> > >should  be treated  in much  the  same way  as Received,  that is,  they
> > >provide a log of message relaying,  that can be examined, but apart from
> > >that,  should basically  be ignored.  (...) That  would imply  that UA's
> > >should  generally  take  no  specific  notice  of  Resent  headers  when
> > >displaying,  replying, etc,  to a  message that  contains them,  instead
> > >using purely the original headers.
>
> This is the historical intent of the ReSent headers.  Believe me, there were
> considerable flames about this back then.  I should know, because MM (which I
> maintained at the time) and Hermes both had this capability as a *distinct*
> capability from forward.  Dave Crocker called it "ReSent" in spite of the fact
> that both the MM (which use Remailed) and Hermes (which used Redistributed)
> communities resented this change.

Well, that isn't what RFC 822 actually says:

          Use of such precedence  information  depends  upon  partici-
     pants'  communication needs.  For example, this standard does not
     dictate when a "Resent-From:" address should receive replies,  in
     lieu of sending them to the "From:" address.

     Note:  In general, the "Resent-" fields should be treated as con-
            taining  a  set  of information that is independent of the
            set of original fields.  Information for  one  set  should
            not  automatically be taken from the other.  The interpre-
            tation of multiple "Resent-" fields, of the same type,  is
            undefined.