Errors-to: owner-drums@CS.UTK.EDU
To: Eric Thomas <ERIC@SEARN.SUNET.SE>
Cc: drums@CS.UTK.EDU
Subject: Re: Comments and Resent-* header fields 
In-Reply-To: Your message of "Sat, 23 Sep 1995 23:25:02 +0200."
             <199509232139.RAA22603@CS.UTK.EDU> 
Date: Sun, 24 Sep 1995 21:54:15 +1000
Message-Id: <20137.811943655@munnari.OZ.AU>
From: Robert Elz <kre@munnari.oz.au>

    Date:        Sat, 23 Sep 1995 23:25:02 +0200
    From:        Eric Thomas <ERIC@SEARN.SUNET.SE>
    Message-ID:  <199509232139.RAA22603@CS.UTK.EDU>

    You are making assumptions about how mail servers and UA work

No, not really, I am sometimes making claims about how they should.

    You're assuming the UA won't show the fields.

No, not at all.   I don't care if the UA shows the fields or
not, in fact its probably easier if they are made explicitly
visible.   They should be able to be seen (not lost) though.

    You're assuming this is the case with all but a few UAs. False.

No, not that.   I am saying that UA's should not (not do not)
allow people to wrap mail in a new envelope and send it without
annotation.

Please recall that the object of standards is to state desired
behaviour, not merely document all existing behaviour.  The
latter is something for book authors.   Standards can be, and
should be, based upon existing implementations, but they should
not be just the union of everything that exists.
    
    You're assuming all but a few UAs will be able to show this
    field to the user. False.

Again I am saying they should be able to, not assuming they do.
Its also interesting that your view of what I assumed changed 100%
between the first paragrah and this one - that should have been a
clue that you weren't understanding what I was attempting to say.

    Any self-respecting (sic) PC  LAN UA will trash  the entire
    header and you'll  be left with no annotation whatsoever.

Which is not good (we know many of thses things are hopeless), but
not a disaster.   Nothing breaks because of that, other than the
ability of the recipient to know the mail was redistributed to
him, not sent directly.

    And don't tell me that it's a gatewaying problem...

OK, I won't - but it is.

    So the annotation function that helpdesk people will want to
    implement and recommend is the one that works in all cases,
    ie in the body.

I am not sure what you are suggesting here.   If you're suggesting
leaving something just like Resent-*, but sticking it in the
body of the message, rather than the headers, as that way the end
users will see it, then I think I will object - mailers should
never mangle the body of the message (it is bad enough when they
mangle the headers).

If you're suggesting forwarding by encapsulation, so the original
message is in the body of a new one, then whether this is right
depends upon the effect intended.  If I receive some mail, think
its great, and want to forward it to others for a good laugh (or
whatever), then encapsulation for sure.   On the other hand, if
I receive a message, that should have been sent to you instead
(eg: sometimes people send me, as list-request, mail that should
have been sent to the list, and ask that I forward it), then
the aim is that the message you get looks just like the message
you would have received had it been sent directly to you.   It is
useful, but not 100% required that you be able to see that I
was involved in getting it to you.   These two kinds of resending
of a message are quite different, and should be treated that way.
    
    >    There's the well-known, silent forwarding  where you just change the
    >    envelope address.
    >I don't think  this is well known,
    It is called a '.forward' file under unix and seems very popular :-)

That is not forwarding in this sense at all, recall we're
discussing cases where some human examines the message and
decides that someone else should get it (as well, or instead,
of the original recipient).   Automated forwarding of everything
is not really related, Resent-* headers should not be added in
that case.

kre