🚀 go-pugleaf

In article <1992Dec28.171751.25819@chance.gts.org>, john@chance.gts.org
(John R MacMillan) wrote:
> 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.  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.

> 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.

> In a local authority, there's no need for a standard

This is quite entirely wrong, no IMHO about it.  :-)  Even in a local
authority, there is software that needs to interoperate, which means
standards are needed.

> probably want something much tighter than a standard could be, so that
> negative responses definitely meant something.

But if I can guarantee the integrity of my mailsystem at a given point in
time, then I have made negative responses mean something.  I think that's
doable 99.9% of the time in a small-to-medium-sized domain.  I at least
want the opportunity to try, which the lack of standards prevents me from
having.

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.
--
Steve Dorner, Qualcomm, Inc.