Subject: Re: Return Receipt et al

From: Joe Ilacqua <[email-masked]>
Date: Tue, 02 Mar 1993 16:32:39 -0500

<On the contrary, I have heard rumors of exactly that possibility on a
>commercial e-mail system, and I've seen articles in the trade rags about
<electronic delivery of legal process.

	But that doesn't make it true or even believable.  Even with
read-receipt I can never prove you read it.  But this is an issue for
"misc.legal", not here.

	Email has become a common communications tool that people use
every day like, phone, fax, or real mail.  It is also become
increasingly reliable.  Pretendeding it isn't or worse deliberately
working to to keep it from becoming more reliable is silly.  I agree,
the issue of read-receipt is a hairy philosophical one.  But the issue
of "Did sending this message work?" is not.

	Back to the issue at hand.  Many of my Pine users know what
"Return-Receipt-To:" does and would like not to have to switch to
another MUA when they want to use it.  Therefor I would like to see
it, or user definable headers, in the next release of Pine.

->Spike

---

From: "Steven D. Majewski" <[email-masked]>
Date: Tue, 2 Mar 1993 17:16:34 +22306404 (EST)

> it, or user definable headers, in the next release of Pine.

I (personally) don't often use "Return-Receipt-To:", but two of the
"missing" features that most often send ME to use another mailer are
user-defined headers ( or being able to edit-headers ) and mush's 
'pick' command. ( Except I would rather that 'pick' changed the view
of the current folder - like sort, but it would temporarily drop 
messages. The mush action of outputing a msg-list wouldn't fit very
well into the Pine User Interface. )

User-defined headers have been mentioned before as being difficult 
to parse and verify. And PINE wants to support the idea of making 
the mail-headers "fool-proof" (i.e. protected).

How about adding a list of allowable additional headers and a 
minimal maybe a minimal grammar to specify that some headers 
contain addresses, and SHOULD be parsed, and others contain a 
vanilla string ( and should just be checked for non string chars. ) 

If the field definition said something like: 

Sender: <address>  "default address" 
Return-Receipt-To: <address>
X-Something <string>

Then Sender and R-R-To: are parsed/checked to ensure they are valid 
conforming fully qualified addresses ( and checked against the address
book on the way. ) while X-Something is only checked that it doesn't 
have any funny embedded chars. 

( BTW: My typical use for editing or extending headers is to 
  modify the Sender:, From:, & Reply-To: fields when sending out
  something in my Bosses name. The secretaries here would have the
  same need, but they aren't as adept with the mail software to 
  figure out how to do it, so it would be nice if there was a 
  "form" capability to set up the proper RFC-822 recommended 
  headers for this type of situation.  Extract from the appropriate
  portion of RFC822 included for illustration. ) 

===============================================================================
 Steven D. Majewski			University of Virginia 
 [email-masked]			Box 449 Health Sciences Center
 Voice: (804)-982-0831			1300 Jefferson Park Avenue
 FAX:   (804)-982-1616			Charlottesville, VA 22908