Errors-to: owner-drums@CS.UTK.EDU
Message-Id: <199509220702.DAA17129@wilma.cs.utk.edu>
To: drums@CS.UTK.EDU
Subject: Comments and Resent-* header fields
cc: moore@CS.UTK.EDU
From: Keith Moore <moore@CS.UTK.EDU>
Date: Fri, 22 Sep 1995 03:02:29 -0400
Sender: moore@CS.UTK.EDU

(from the chair) 

I. Comments field

I haven't seen any objections to the suggestions that:

+ the Comments field SHOULD NOT be used to convey important information
  to the recipient, since many UAs won't display it by default,
  (in particular, it SHOULD NOT be used for a description of the message
  body, since that's covered by the MIME Content-Description field)

+ the Comments field MAY be used by mail-handling software to
  annotate the message, especially to insert free-form trace and/or
  debugging information,

Barring strong objections expressed in the next few days, I'll assume
we have concensus on this view.

II.  Resent-* fields

Based on the discussion about UA behavior in the presence of Resent-*
and on the historical meaning of Resent-*, I suggest that we clarify
822bis to say something that:

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

  There are few legitimate uses for such a facility, but examples
  of such use might include: 
  
  - re-sending of misdirected mail to the correct address, or 
  - for use by a human "dispatcher" that pre-scans incoming messages, 
    assigns a specific person to act on each message and reply to it, 
    and then "re-sends" the message to that person.  

  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.  

  (Should we deprecate or discourage RFC 934 encapsulation?)

+ Resent-* headers are not intended to serve as reply addresses.
  However, in rare cases it may be useful for a recipient of a "resent"
  message to reply to the person who "re-sent" the message; UAs MAY 
  provide such a facility.

+ 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?)

+ MTAs or other mail processors MUST NOT refuse to deal with a message 
  based on the presence or absence of any Resent-* headers (including
  if they don't appear in matched sets.)  (I'm told that some mailer 
  out there does this, but I forget which one.)

...along with some language about how to "Resend" a message
(e.g. delete any Return-Path fields, use the resender's address in the
envelope MAIL FROM and in the Resent-From field (or Resent-Sender if
the person doing the resending isn't the one authorizing the
resending), put the current date in the Resent-Date field, place a new
message-id in the Resent-Message-ID field.  I'm not sure
Resent-Reply-To has any useful purpose in this context; perhaps it
should be deprecated.)

Note that this still doesn't deal with multiple sets of Resent-*
headers, but maybe that's such a marginal case that we need not worry
about it. 

Alternatively, we could deprecate Resent-* altogether.  RFC 934 argues
that "resending" (which it calls "distribution") isn't needed.
Instead, it suggests that UAs have a "burst" command that removes
encapsulated messages.  (MH provides such a command, but most UAs
don't seem to have that feature.)

It would appear that we are leaning toward keeping Resent-* and simply
specifying a set of very limited conditions under which it may be
used.  Those who still feel that we should deprecate it should speak
up now.

Keith

p.s. Incidentally, RFC 934 defines several terms which might be useful in
our discussions and/or specifications: Originate, Reply, Forward, and
Distribute.  (We will also need to distinguish manual Forward-ing from
autoforwarding.)