Talk:Return receipt

Delivery Status notification (DSN)

This article and wikipedia in general assume this is a failure advice. The RFC allows for positive delivery notifications as well ie a return mail advising your correspondence has been delivered to the address or placed in the account. While very few server support this positive form, it is specified and turned off on servers to help stop t6he validation of email addresses by spammers. Glossing over the topic with calling is a non delivery notice is just wrong. MadMatt Au (talk) 00:56, 8 February 2013 (UTC)

what does "return receipt" mean in the email world, anyway?

I'm not entirely happy with my discussion of the meaning of "return receipt" as applied to email. But I've seen so much confusion result from use of the term and the difference between the service you get in email and the service you get from a physical delivery system, that I felt compelled to write something about it. What's usually thought of as "return receipt" in the physical world really doesn't exist in standards-based email. Keithmoore (talk) 20:20, 6 June 2008 (UTC)

I suspect that it would be better to cut the e-mail section back and move a lot of it to bounce message. Then, this article could be rephrased much more in the terms of "return receipt" vs bounces, and e-mail vs real world. I notice it doesn't currently mention bounce at all, and the link to Delivery Status Notification (which redirects to bounce message) was removed. Wrs1864 (talk)

I've re-read the article and ponder some more. I'm not sure that a lot of this really could be moved to the bounce message article, but some could and a link should definitely be restored. Also, I would think that something about "message tracking" (RFC 3885) would be useful to include. Wrs1864 (talk) 21:21, 6 June 2008 (UTC)

Article content is false

There exists no means by which delivery can be ascertained. The IETF RFQs merely define methods by which email can have as high a reliability as possible. The premise that acknowledgment of receipt must precede delivery is not true, which makes the article's assertion false. Assurance of delivery to a machine is not the same thing as assurance of electronic receipt by a person who uses the machine. At best, a service can provide a "best effort" between machines.

The statement, "... there is no way to prevent that computer system from making the message available to the recipient without issuing an acknowledgment to the sender." is likely a typographical error of some kind. Among the many reasons this must be so IETF 3463 states, "Note that the Reporting-MTA is not necessarily the MTA which actually issued the DSN."

I'm making this Talk entry with the hope that the original author (or an admin that can help with the clarity) edits the article or removes it. Maybe I've somehow misunderstood the article content. Will return on another day to follow-up. Kernel.package (talk) 20:47, 15 June 2010 (UTC)

I agree, this is definitely false information, can't we just edit that sentence to say "there is A way"? using the old outlook express mail client, the question below pops up when receiving an email that requests a receipt "the message has requested a response to indicate that you have read this message. Would you like to send a receipt ?" and the user can select yes or no

see the section on more information here in microsoft's kb: NOTE: The e-mail program your intended recipient uses must support returning read receipts for you to receive one. Also, message recipients can choose not to send read receipts, even when they are requested. If you do not want to send receipts, click Options on the Tools menu, click the Receipts tab, and then select the Returning Read Receipts option you want.

Chop2x (talk) 08:17, 18 August 2012 (UTC)

References

Confusing

This article appears to deal with at least two completely different subjects, a postal service and an email function. Philafrenzy (talk) 23:54, 29 July 2013 (UTC)

Edited to restrict just to email. Avis de réception covers the postal angle. Philafrenzy (talk) 11:07, 15 December 2013 (UTC)

No mention of WhatsPP

--84.147.34.33 (talk) 23:25, 1 January 2019 (UTC)