🚀 go-pugleaf

In article <1992Dec28.171751.25819@chance.gts.org> john@chance.gts.org (John R MacMillan) writes:
| My position on this is that receipts are only genuinely useful if they
| are guaranteed.  Since we can't get this with the loose email net we
| have, it's not useful.

My past experience with the LLNL EM code with the Air Force and several
other US government organizations does not agree with this.  Our ability
to provide both return receipt and delivery notification functionality
to our clients was a significant reason that they used the software.  It
was heavily used, and found to be quite useful by most of the people using
the software.

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

In most of the cases, a positive response is all that is required.  Keep
in mind if there was a problem with delivery, many times a negative
acknowledgement is sent, although this is not guaranteed.  

Assuming you make the final delivery program responsible for the delivery
report, and this reports makes its way back to the originator of the message,
I don't understand your comment about the system not being foolproof.

| User expectation is perhaps the biggest problem.  As a side story, I
| used to work at a place where the admin staff used a "friendly" mailer
| that had read receipts.  One user got very confused because she would
| get replies to her mail, and a day or so later get told by the
| friendly mailer that the recipient had not yet read the mail, even
| though she'd seen the reply.  When the cause was explained, she
| couldn't see the point of the read receipt feature because she was
| expecting something more meaningful.

Sounds like broken software to me, not necessarily an argument against the
functionality.

Best Regards,

Tim Kehres