🚀 go-pugleaf

In article <2050@ltb.ltb.bso.nl> wierda@ltb.ltb.bso.nl (Gerben Wierda) writes:
>As I recall, under 2.1 the NeXTmailer just looks for "NeXTmail 1.63RR"
>somewhere in the header and decides upon the RR (return receipt) that it has
>to return an acknowledge.

It seems to me that it would have been cleaner if NeXT had just inserted 
another header line, rather than mucking about with a comment.

>I have seen "Return-Receipt-To: name@address" also. That seems a logical
>extension to the mail protocol. Is NeXTmail under 3.0 doing this, or doing the
>old thing (backward compatibel) or doing both? Looks handy to have that
>working for other mailprogramns too.

Gack!  This RR thing is such a kludge!  I'd had to see it propagated
to other mail UAs.  Much better to use another header line and attempt
to get consensus on that.  

"Return-Receipt-To:" is a different matter.  "Return-Receipt-To:" is a
non-standard extension to RFC-822 which is implemented by the sendmail
MTA.  It causes a message to be returned when the message is
*received* by the host and dropped into a user's mailbox.

The intent of the NeXT "RR" feature is to return a message when the
user actually *reads* the message.

Neither of these mechanisms can be depended on in the general case; if
a host your are sending mail to doesn't use sendmail, it won't do
anything with the Return-Receipt-To: header line.  If the user your
are sending a mail message to doesn't use the NeXT Mail.app program to
read his message, then no return recept will be returned when the
message is read.  For instance, I use MH rather than NeXT's Mail.app
to read mail on my NeXT.

Also, some have found it rude to have their mail UA return an
acknowledgement automatically when a message is read, and have patched
their Mail.app to inhibit this behavior.