Splash wrote:
> Ok, Where is this information pulled from? At two locations email is sent and
> recieved. when sent from M1 a reead receipt is requested. At M2 the message
> is received and subsequently asked to send read receipt. At this point the
> reader tick the "ok to send read receipt" and the receipt is sent. The reason
> I ask, is that prior the "read receipt" contained information on the email
> that is being receipted, like the subject, date and time, and some verbage
> regarding what the read receipt meant. Now, the body contains nothing. Where
> is this controlled?
Only the headers for requesting a read/delivery receipt are defined.
Nothing is defined as to the content of the new e-mail that gets sent by the
recipient back to the sender as the acknowledgement of that request (i.e.,
the recipient's e-mail client determines what to put into the new e-mail
sent to the sender as the "read receipt"). The recipient's e-mail client
decides what to put into the new e-mail sent back to you as the receipt.
You never identified what the recipient uses for their e-mail client, and
outside a controlled test or work environment then you won't know.
Read receipt *requests* (which is a header in the e-mail) are handled by the
recipient's e-mail client. Whether the e-mail client prompts, always sends,
or always ignores these requests depends on how the user configured their
e-mail client. The default in most e-mail clients is to prompt when a
sender has requested a read receipt. This prompt usually spurs the user to
configure their e-mail client to ignore all such further requests as they
are not interested in divulging to the sender as to if and when they read
the sender's e-mail.
Delivery receipt *requests* (which is a header in the e-mail) are handled by
the recipient's mail host (NOT by the recipient's e-mail client). It is a
request for the receiving mail host to notify the sender that their e-mail
got to the recipient's mail service. It does NOT validate that the e-mail
got through that mail service to the recipient's mailbox and it is does not
validate that the recipient retrieved the e-mail in their e-mail client and
then opened that e-mail. Rare few mail hosts waste their time with positive
feedback via delivery receipts. They don't need to tell you when your
e-mail was accepted by their mail host. Instead they send back negative
feedback when their mail host rejects or otherwise will not or can not
accept your e-mail. The lack of negative feedback is the positive feedback.
Mail hosts don't need to waste their time validating all accepted e-mails
and instead they just need to provide the negative feedback when they cannot
accept your e-mail (or the sending mail host sends back the negative
feedback when it cannot connect to the receiving mail host).
Read receipts: Requests are handled by recipient's e-mail client.
Most users ignore all such requests.
Delivery receipts: Requests are handled by the receiving mail host.
Most mail hosts ignore such requests.
Read or delivery receipts are a *request* made by adding a header to the
outbound message. The name and value of these headers are defined by RFC or
were defined by common usage (i.e., de facto standards).
Delivery receipts are handled by the recipient's mail server and as such
provide no proof that the message was actually placed in the recipient's
final mailbox (since there may be further internal routing before reaching
the mailbox) or that the recipient was able to retrieve the message. Few
mail servers waste their resources to respond to delivery receipt requests.
They will reject a message during a mail session with the sending mail
server if they know the message is undeliverable which results in the
sending mail server issuing an NDR (Non-Deliverable Report) message back to
the sender, or they accept the message and later issue an NDR if the message
is found to be undeliverable but after the mail session with the sending
mail server was ended. They are not interested in expending their resources
to send back positive feedback for the much higher volume of deliverable
messages since the lack of the negative feedback (reject during mail session
or NDR sent later) is itself the positive feedback.
Read receipts are handled by the recipient's e-mail client; that is, not
only must the message be delivered to and accepted by the recipient's mail
server and then get to their mailbox but the recipient must also be able to
successfully retrieve and also view the message. Retrieving the message
into the recipient's e-mail client is not sufficient to issue an
acknowledgement (receipt). The recipient must actually open or view the
message in their e-mail client. Most users will say No to a prompt to send
the acknowledgement message or they configure their e-mail client to always
ignore the request. Not all e-mail clients support read receipt handling,
especially webmail clients.
When read or delivery notifcations are requested by the sender, one of the
following headers are in the received copy of the e-mail:
Read-Receipt-To
Return-Receipt-To (for delivery receipt requests)*
Return-Receipt-Requested
Disposition-Notification-To (for read receipt requests; RFC 3798)*
Generate-Delivery-Report (for delivery receipt requests)
* Used by Microsoft Outlook.
Some are obsolete or non-standard (but may be de facto standards); however,
Microsoft has used them at some time. Only the last 2 are standardized by
RFC. These headers have as their value the e-mail address to which the
acknowledgement message (i.e., the notification or receipt) gets sent.
Because the Disposition-Notification-To header is defined by RFC 3798
(
http://www.ietf.org/html/rfc3798), so also is its MDN (Message Disposition
Notification) format, the content of the acknowledgement, defined by that
RFC. Although widely used, Return-Receipt-To is not an RFC standard header
(see
http://www.ietf.org/rfc/rfc2076.txt) but instead a de facto standard so
it may not be recognized by all e-mail clients (for those that support read
receipt handling). Also, its acknowledgement message (i.e., receipt) is not
defined by RFC so there is no standardized format for a delivery reciept.
RFC 3503 (
http://www.ietf.org/html/rfc3503) addresses how MUAs (Mail User
Agents), like Outlook, are to handle MDNs when IMAP is involved. However,
Outlook is known to have more problems with its IMAP support than do other
e-mail clients. This RFC was ratified in 2003 but it can take up to 6 years
before e-mail clients adopt RFC standards (and only if they choose to adopt
them).
Similar Threads
