Errors-to: owner-drums@CS.UTK.EDU
Message-Id: <199509222327.TAA28462@CS.UTK.EDU>
Date:        Sat, 23 Sep 1995 01:01:06 +0200
From: Eric Thomas <ERIC@SEARN.SUNET.SE>
Subject:     Re: Comments and Resent-* header fields
To: drums@CS.UTK.EDU, Keith Moore <moore@CS.UTK.EDU>
In-Reply-To: Message of Fri, 22 Sep 1995 03:02:29 -0400 from moore@CS.UTK.EDU

On Fri, 22 Sep 1995 03:02:29 -0400 Keith Moore <moore@CS.UTK.EDU> said:

>+ Resent-*  fields  are intended  for  use  when "manually  relaying"  a
>  message to a  recipient so that it  will be treated as  if the message
>  were sent directly from the author to that recipient.
>
>  That is, they should be used to note when a human takes a message that
>  has already been  delivered, wraps it in a new  envelope, and sends it
>  to one or  more recipients with no additional  annotation, cover note,
>  etc., beyond the Resent-* headers themselves.

All right...

Case 1,  you are  resending the message  to a piece  of software  (a mail
server) that will take action based  on the contents. Case 1.a, you don't
want the  software to take  any action on  the Resent- fields.  Well, why
insert them at all then? Isn't it simpler and more predictable not to add
them in  the first  place? Case  1.b, you  do want  the software  to take
action on the  Resent- fields. This contradicts the rest  of the proposal
and in particular the fact that there  is no clear definition of what the
"correct" behaviour  should be in  that case  (most people on  this group
seem to say "just ignore it" - see 1.a).

Case 2,  you are resending to  a human person.  While you do not  want to
annotate or edit the  message in any way, you want  the recipient to know
that you resent it. You also  want the recipient's replies to be directed
to the  original sender, and  not to you.  These are just  the hypotheses
from the description, listed in another  order. Well, I contend that this
is not an appropriate  function. If I forward a message  to Joe such that
it shows up as coming from me, but replies will actually go someone else,
I am  basically sending  Joe a  poisonous gift,  especially given  that I
can't annotate  to bring this problem  to Joe's attention. Of  course Joe
could be an e-mail expert and know everything about it. But, as a general
purpose  function, it  doesn't seem  very appropriate  to me.  We're only
going  to be  saying SHOULD  anyway,  so e-mail  experts are  free to  do
whatever they want in the cases where it really makes sense.

All in all  my impression is that  the people who use  Resent- fields for
mail servers do so  because there is no command in  their mail program to
forward a message  "as is", without any header change.  I don't think the
standard is the right item to change :-)

>  For most cases when a message is manually forwarded to a new recipient
>  (and always when  additional information is being added  by the person
>  doing the forwarding), Resent-* fields  SHOULD NOT be used. Instead, a
>  multipart MIME message SHOULD (MAY?) be constructed which contains the
>  original message as a component.

Well, at best this can be a  long-term goal. Most current mail servers do
not have support for multipart MIME  messages sent to the server address.
In fact it's  a situation where it  may not be 100% clear  what the Right
Action is. Sometimes the user is allowed to annotate the message and this
shows up as a  separate text part. In the case of a  server, should it be
processed? How? Should be it treated  as two (or more) separate messages?
Where should the (respective?) replies go? I don't think this is a simple
issue.

>+ Resent-*  headers SHOULD  NOT be  added by  an MTA  when automatically
>  forwarding mail. (but do we need some way to annotate this? perhaps in
>  the Received header?)

I agree with  the basic idea, however forwarding can  be a complex issue.
There's  the well-known,  silent  forwarding where  you  just change  the
envelope address. Then  there's the case where you want  to annotate with
an automatic message. In between there's the case where you want to leave
a visible trace that the mail was  forwarded and where, but don't want to
annotate. I don't really have a strong opinion on any of this. Personally
I never use  Resent-* for automatic forwarding. I'm just  not sure we can
make a  generic statement about  mail forwarding  when there are  so many
specific cases.

>  (I'm told  that some mailer  out there does  this, but I  forget which
>  one.)

That's true, and it's a UK product :-)

>Alternatively, we could deprecate Resent-* altogether.

In the long  term, it may indeed  become obsolete. But right  now I think
"forwarding" (either  manual or automatic)  isn't defined well  enough to
allow us  to make broad  statements about what  should and should  not be
done.  Personally I'd  rather deprecate  than apply  the change  that was
proposed.

  Eric