Subject: Re: Headers

From: [email-masked] (Ken Hardy)
Date: Fri, 15 Oct 93 12:36:15 CDT

Adam J Weitzman <uunet!individual.com!weitzman> writes:

>since RFC-822 essentially allows you any darn header you please in an
>email message, why not have a facility that allows the user to do just
>that, put in any header they want?

Although I maintain Pine for those users who need/prefer it, I use
Sun's mailtool myself, and it has just such a facility -- I used it to
add the "Reply-To" header on this message so that any responses should
go to the list automagically.

Do the authors of Pine use only Pine?  It's a great application, but
they're wearing blinders if they don't survey what's being done by
other applications in the same field.  (They're probably well informed,
and it's just a matter of reaching a consensus of what's worth doing
and what's not.)

Letting the user add any header desired keeps the Rich Headers option
from getting too big and avoids the shortcomings of petrifying a list
what headers can be added.  Some applications (like the anon.penet.fi
anonymous mail server) use "X-*" headers of their own design.  I think
it's worth serious consideration.

--
Ken Hardy
[email-masked]  (racerx!ken) --__-_____--__-__--_--__-___-__-__-___----

---

From: Terry Gray <[email-masked]>
Date: Fri, 15 Oct 1993 11:17:58 -0700 (PDT)

> >that, put in any header they want?

I personally lean toward a laissez faire approach to headers, but be
advised that not everyone agrees that this would be desirable.  In the
past, some mail agent authors have been flamed for permitting arbitrary
headers because of their potential for perceived "abuse".  Alas, we have
at least our share of mischief makers. 
 
> go to the list automagically.

Yes, but this is a good example of what I would consider *mis*use of the
Reply-To: field.  LISTSERV's are often configured this way, and it has 
caused enormous embarrassment to individuals who thought they were 
replying to an author, only to find their msg in thousands of mailboxes.
Fortunately, Pine gives you the option of ignoring the reply-to field, so 
that you get to *choose* where your response goes.
 
> and it's just a matter of reaching a consensus of what's worth doing

The pine team *tries* to keep up on current events, but we always
appreciate efforts to educate us... 

There is a consensus issue, but there is even more a *time* issue.  This is
only one of *many* enhancement requests.
 
> it's worth serious consideration.

Rest assured that it is getting serious consideration.  But also keep in 
mind who is funding this project.  In the 3+ years that Pine has been 
around, I believe that virtually all the requests for additional header
support have come from other sites.  With possibly very few exceptions, 
their absence has not been noticed by our constituency.

Having said that, I will state one more time, just to be really clear:
we will be providing additional header support in a future release.
Whether to permit arbitrary user-defined headers is not yet decided,
for the reason mentioned above, but Reply-To will certainly be there one 
way or another.

-teg

---

From: Ed Greshko <[email-masked]>
Date: Sat, 16 Oct 1993 16:33:44 +0800 (TPE)

> at least our share of mischief makers. 

	I don't think it is so much a "preceived abuse" but a risk to
interoperability.

	As an example...  It doesn't matter whether or not you compile
MIME support into elm, elm will always generate a "Content" header.
A certain application at our site was checking for "Content" header to
determine if the message was MIME so it could further process the message.
The application failed since the message was not really MIME compliant.
Granted, the application should have been checking for the "Mime-Version"
header instead of the "Content" header.....maybe....since without the
"Mime-Version" header the "Content" is not defined and therefore should
not appear in a message.

	I believe that RFC-822 is quite clear in its intentions and
definitions.  If you are going to implement the headers defined in 822
(and its extensions) you must do so as defined.  If you wish to use 
headers not defined in the RFCs then you need to preceed it with an
X.  The reasoning is clear, in that later RFCs may define a header
that you have chosen to use and you may end up "breaking" compliant UAs.

	Remember too that RFC-822 and its extentions only tell you how
you must implement the defined headers.  It doesn't say you have to
implement them all.

> that you get to *choose* where your response goes.

	I like the fact that pine gives you the choice...but I can do without
it since I'm a more experienced email user.  For the less educated email 
user it presents a dilema.  "When do I say yes?  When do I say no?  If I
say no can I be sure my reply will get there?"  I would say leave the
decision of adding the "Reply-To:" field with the sender.  If it causes
"enormous embarrassment" it will not be the end of the world and the
user will learn a few things from it.  Not the least of which would be
to be more careful of what is said in email.

> only one of *many* enhancement requests.

	I'm very sure the Pine authors are up-to-date on what is happening
in the world of email.  As far as I know, there is no UA in existence that
implements all of the possible features in all of the possible combinations
in all of the possible ways that everyone will like.  (Just be happy they
don't have to decide on what features of X.400 they should implement.)

	I for one am thankful that there isn't enough time to implement
all of the "*many* enhancement requests".  To do so would drive Pine to
the level of complexity it seeks to avoid.
  
> their absence has not been noticed by our constituency.

	"X-*" headers of their own design" only make sense if they
convey information that the receiving UA understands and can make use of.
While I see some justification for them I also see the potention for
misue much like the *huge* .sigs I've had to endure.  Should the
authors of Pine decide to allow them I hope they also make it optional
to display them.

	That said, I'd vote for minimum additions to the "Rich Headers"
field and the ability to include a file of user defined headers on
which Pine would enforce the "X-*" convention.
 
> for the reason mentioned above, but Reply-To will certainly be there one 

	Thank you for considering it.  If I wore one, I'd take my hat off
to the Pine Team for being as sensitive as they are to indivduals outside
of their community.  And even if they decide against adding this feature
there are at least 2 alternatives...move to another UA or start hacking.
I, for one, would rather hack than switch.  :-) :-)

Edward M. Greshko			Control Data Taiwan
Voice: +886-2-715-2222 x287		6/F, 131 Nanking East Road, Section 3
FAX  : +886-2-712-9197			Taipei, Taiwan R.O.C