Errors-to: owner-drums@CS.UTK.EDU
To: Keith Moore <moore@CS.UTK.EDU>
Cc: drums@CS.UTK.EDU
Subject: Re: Comments and Resent-* header fields 
In-Reply-To: Your message of "Fri, 22 Sep 1995 03:02:29 -0400."
             <199509220702.DAA17129@wilma.cs.utk.edu> 
Date: Sun, 24 Sep 1995 05:46:43 +1000
Message-Id: <19985.811885603@munnari.OZ.AU>
From: Robert Elz <kre@munnari.oz.au>

    Date:        Fri, 22 Sep 1995 03:02:29 -0400
    From:        Keith Moore <moore@CS.UTK.EDU>
    Message-ID:  <199509220702.DAA17129@wilma.cs.utk.edu>

    + the Comments field SHOULD NOT be used to convey important information
    + the Comments field MAY be used by mail-handling software to
    annotate the message,

Sounds good.   I'm not sure exactly why we're bothering much
with this though, I don't think it was on the list of problems,
probably because Comments have never been a problem in any
real way (other than perhaps usage neglect, but that's OK).

    + Resent-* fields are intended for use when "manually relaying"

Sounds good to me.

    There are few legitimate uses for such a facility,

Who cares?   I actually think its used enough, and probably
should be used more than it is.


    (Should we deprecate or discourage RFC 934 encapsulation?)

No please, its a really nice, easy, and pleasent looking way of
doing message encapsulation.   It is also used by many digests.
If you bounce a message from munnari.oz.au (send to bogususer@)
you'll get back a 934 encapsulated bounce, all ready for MH's
burst command...   (the message won't be rejected at the smtp
dialog becase of the way I do user lookups on munnari, any
unknown user may be known on another system here, so I accept
everything and bounce later if the other system rejects it).

    + Resent-* headers are not intended to serve as reply addresses.

Yes, sounds right.

    + Resent-* headers SHOULD NOT be added by an MTA when automatically 
    forwarding mail.

Agree.

    (but do we need some way to annotate this? 
    perhaps in the Received header?)

No, I don't think we really can, though as a list maintainer it
would be really nice to be able to figure out which address
finally reached the system that bounced it (that system not being
on the list anywhere).  Sometimes the Received headers give a
clue, but not always.
    
    + 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.)

Agree.
    
    Resent-Reply-To has any useful purpose in this context; perhaps it
    should be deprecated.)

Perhaps.   One other possible usage (no particular argument for
this) would be to allow that one to be an overriding Reply-To.
That is, to allow the person dispatching the message to direct
where replies should be sent, and have that take preferencee for
default replies from the final recipient over all other headers.
That could be useful, but I doubt its implemented that way
anywhere (I have not seen it), so is probably not practical, and
would come close to new functionality.
    
    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. 

I disagree there, we need to say something about this, even if
it is just how old Resent headers should be buried (not deleted)
before adding new ones.
    
    Alternatively, we could deprecate Resent-* altogether.

No.

kre