confirmation of delivery??

[Ruth]

Hi

I want confirmation that an email has been delivered/received. In the
options I checked the box for delivery confirmation. I get an email back
stating:

Delivery to these recipients or distribution lists is complete, but delivery
notification was not sent by the destination:

does that mean it was delivered-- or is there a problem that occured?

 

[Roady [MVP]]

It means that the message has been delivered to the mailbox on the server
successfully. The notification only stresses the fact that a delivery
notification cannot confirm that the message also got delivered to client
the recipient is using to read his/her email. So the delivery has been
confirmed by the server and not by the recipient itself.

 

[M]

That delivery confirmation might have come from an e-mail server in the
senders's organization to let her know that the message left her
organization. Not every e-mail system will generate a confirmation. And the
confirmation might come from one of the "main" e-mail servers, not the
actual recipient's mailbox server. Some systems won't even generate an error
if the recipient wasn't valid.

I don't know if there's an actual RFC standard for delivery/read
confirmations. And if there is, most vendors probably implement them
differently and have options to enable/disable them. My point is that you
can't really depend on the message delivery/read recipients, especially for
recipients outside of your organization.

--
Regards,
M
MCTS, MCSA
http://SysAdmin-E.com

It means that the message has been delivered to the mailbox on the server
successfully. The notification only stresses the fact that a delivery
notification cannot confirm that the message also got delivered to client
the recipient is using to read his/her email. So the delivery has been
confirmed by the server and not by the recipient itself.



-----

 

[Brian Tillman [MVP-Outlook]]

That delivery confirmation might have come from an e-mail server in the
senders's organization to let her know that the message left her
organization. Not every e-mail system will generate a confirmation. And the
confirmation might come from one of the "main" e-mail servers, not the
actual recipient's mailbox server. Some systems won't even generate an error
if the recipient wasn't valid.

My interpretation is that the sender targeted a mailing list on a listserv and
that the list server that received the message is the entity replying with the
read receipt. Who knows whether it delivered the message to the list members.

 

[VanguardLH]

Hi

I want confirmation that an email has been delivered/received. In the
options I checked the box for delivery confirmation. I get an email back
stating:

Delivery to these recipients or distribution lists is complete, but delivery
notification was not sent by the destination:

does that mean it was delivered-- or is there a problem that occured?

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

 

[VanguardLH]

And some more info (with some repeated):

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