Errors-to: owner-drums@CS.UTK.EDU
Message-Id: <199509182018.QAA11298@CS.UTK.EDU>
Date:        Mon, 18 Sep 1995 21:54:57 +0200
From: Eric Thomas <ERIC@SEARN.SUNET.SE>
Subject:     Re: Resent- facility
To: Robert Elz <kre@munnari.oz.au>
cc: ietf-drums <drums@CS.UTK.EDU>
In-Reply-To: Message of Tue, 19 Sep 1995 05:38:35 +1000 from Robert Elz
             <kre@munnari.OZ.AU>

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.

Well, there is  a significant user base that has  been consistently doing
exactly   the  opposite,   taking   "Resent-"  tags   to  supersede   the
corresponding non-resent tags. This is the  way I read the standard and I
guess  it's   another  of   these  philosophical  differences.   From  my
perspective,  there are  two compelling  reasons why  "Resent-xxx" should
supersede "xxx" and not simply be ignored:

1. If  you "resend"  a message  to me  and my  UA completely  ignores the
   "Resent-" lines, I am  going to be scratching my head  in search for a
   reason why "the system" sent me this thing which was obviously not for
   me. Being  a technical  person I  would know  to search  for "Resent-"
   lines and how to make my UA show these tags. If I were Joe PC User, on
   the other  hand, I'd call the  support folks to report  ANOTHER BUG IN
   THE  MAIL SYSTEM  and ask  if this  is how  much they  care about  the
   PRIVACY OF  PEOPLE'S MAIL because this  could have been the  message I
   sent my girlfriend this morning  landing into someone else's in-basket
   by mistake.

2. If  the only purpose  of the  tag is to  be ignored, providing  only a
   "Received:" like trace, this would  have been clearly specified in the
   standard. It  would not say "This  new field is treated  as being more
   recent than  the equivalent, original  field", it would say  "This new
   field is  a comment,  providing a  trace of  the forwarding  event for
   troubleshooting purposes".

Actually, what's interesting is that where RFC822 mentions forwarding, it
describes the  "Resent-" method. Historically  this is the method  that I
remember being used by virtually everyone (at least everyone who wrote to
me :-) ). Then one day someone decided that it was better to make a brand
new message  envelope, I  assume to  get around some  bug in  some common
piece  of software.  Now  we're talking  about  possibly deprecating  the
original  "forward" function.  I've  never seen  a  clear description  of
what's broken  with it, setting aside  that popular UA/MTA such  and such
might barf  on the  headers and  therefore the  standard was  wrong. I've
always used  "Resent-" and never  had a problem  with it, except  where a
"Reply-To:"  tag was  present and  the target's  UA didn't  ignore it  in
favour of "Resent-Reply-To:". It's a common problem so I routinely delete
the Reply-To: when I'm forwarding to a non-technical person.

Besides, as  a user, I  get ultimate  control with the  "Resent-" method.
Half of the forwarded messages I get are of the type "Have you seen this,
what do you  think, is what they say  true?" Then I want to  reply to the
person  who  forwarded  the  message  to me,  which  is  easy  with  both
forwarding  methods, provided  that  you use  "Resent-"  tags. The  other
messages are  from colleagues who  got a question  from a user  that they
want me  to answer. Then  I want to  reply to the  user and that  is only
convenient with "Resent-".

  Eric