NetNews Usenet Archive 1992 #31/NN_1992_31.iso/spool/comp/mail/headers/383

Internet Message Format | 1992-12-29 | 3.8 KB

Xref: sparky comp.mail.headers:383 comp.mail.misc:4142
Newsgroups: comp.mail.headers,comp.mail.misc
Path: sparky!uunet!uunet.ca!wildcan!sq!chance!john
From: [e-mail] (John R MacMillan)
Subject: Re: Return and read receipts (was Re: Return-Receipt-To & forwarding...)
Message-ID: <[e-mail]>
Organization: $HOME
References: <sdorner-271292095054@0.0.0.0> <[e-mail]> <[e-mail]>
Date: Tue, 29 Dec 1992 18:18:14 GMT
Lines: 68

|> With return-receipt-to, a lack of response means nothing (your message
|> may or may not have been delivered), and a positive response means
|> there's a good chance your message was delivered, but it's my no means
|> foolproof.
|
|The positive response tells me that there is a path to and from my
|addressee.

Lack of a bounce message tells you the same thing with about the same
reliability ("pretty certain" vs. "fairly sure").  Yes there may be
bizarre systems that don't generate bounce messages, but I don't think
that's all that common anymore, and it's becoming less so. :-)

|Yes, there may be bizarre gateway software that fools the
|scheme; but I don't think that's all that common anymore, and it's becoming
|less so.

It's not bizarre, and I doubt it's uncommon.  I have addresses at
several sendmail sites that .forward my mail to a program that either
does something or forwards to my real address.  You'll get a receipt
generated as soon as that program gets run, but if I move and forget
to update it, or if the path from there to my real address goes away,
or my program discards your mail for some reason (an overzealous mail
killfile, perhaps), then you're wrong about the receipt indicationg
you have a path to me.

Now I don't think that the latter half of the above happens often, but
I'm sure there are plenty of that kind of "gateway".

|> With read receipts the same scenario applies.  If you care, an
|> automated response is not enough, and if you don't care, why bother?
|
|That depends on what the purpose of the receipt is.  If the purpose is "If
|you don't press the blue button in the next 30 seconds we're all going to
|die," you're right.  However, if I want some degree of proof that my
|question reached Marshall Rose, it's a different story.

I guess that's where I disagree.  I don't think it is a different
story.  As "proof" your question reached mtr, a receipt is worthless;
it's only an indication.  Another indication that your question
reached him was that you didn't get a bounce message.  I feel that
both these indications carry about the same weight.  If you get a
significantly warmer and fuzzier feeling with the receipt I think
you're just fooling yourself.

|I can certainly understand the objections.  However, people are using the
|non-standard tools we now have (like Return-Receipt-To:), and they seem to
|feel it's worthwhile.  Better to have a standard way of doing this, even if
|we acknowledge we cannot yet perfectly implement it.

This may be true, which is why I wouldn't really discourage anyone
from attempting such a standard, I just want to make sure they think
hard about the issues.

So, as you work on the standard some points to consider:
- _please_ stress in the standard what receipts do and don't mean
- what about receipts only to some receipients?  (maybe
  Return-Receipts-For: (list of addrs))
- proscribed behaviour for mailing lists, gateways, and mail pickup
  services
- some easily automated way to tie the outgoing mail to the receipt
  (presumably by message-id, but you'd want to be able to easily pull
  it out of the receipt).

You might want to also look at other packages that already provide
this sort of thing (SCO's OPmail had read receipts as I recall, I
think attmail has them, there are probably lots of others) just to get
an idea what else might be useful.