delivery receipt problem

O

Owen33

Hi, I have an issue regarding the delivery of emails. A friend can send
emails to me and I get them right away. However, if he requests a delivery
receipt then I don't receive the emails. He gets no notification that the
emails didn't go through. Any help or suggestions would be appreciated.
 
B

Brian Tillman [MVP - Outlook]

Hi, I have an issue regarding the delivery of emails. A friend can send
emails to me and I get them right away. However, if he requests a delivery
receipt then I don't receive the emails. He gets no notification that the
emails didn't go through. Any help or suggestions would be appreciated.

Sounds like your mail server is not accepting messages containg a delivery
receipt request. Delivery receipt requests are handled by the server, not the
receiving Outlook.
 
O

Owen33

Thanks. Is it common for mail servers to not accept messages with delivery
receipts requests? Why would a server be set up that way?
 
V

VanguardLH

Owen33 said:
Hi, I have an issue regarding the delivery of emails. A friend can send
emails to me and I get them right away. However, if he requests a delivery
receipt then I don't receive the emails. He gets no notification that the
emails didn't go through. Any help or suggestions would be appreciated.

Sounds like an anti-spam filter or rule problem. It is blocking e-mails
with delivery receipt headers in them.
 
V

VanguardLH

Owen33 said:
Thanks. Is it common for mail servers to not accept messages with delivery
receipts requests? Why would a server be set up that way?

It is rare that a mail server wastes its time sending delivery receipts
(which the mail server handles versus read receipts which the e-mail
client handles). After all, they already send back negative feedback if
they cannot deliver an e-mail. The lack of negative feedback is the
positive feedback you want.

If you throw a ball out the window, do you need a "window guard" to hand
you a receipt showing the ball went out the window? No. The ball
bouncing off the wall around the window and bobbling about your side of
the window (negative feedback) is all you need to know that it did not
get through the window. That absence of a ball bouncing back (lack of
negative feedback) tells you it went through the window.

Normally the receiving mail server will reject an e-mail during the mail
session with the sending mail server if it finds the e-mail cannot be
delivered. If the receiving mail server accepts the e-mail during a
mail session but later finds out it is undeliverable, it sends back a
new e-mail to the sender (professed in the return-path headers) saying
the e-mail could not be delivered. If your sending mail server cannot
establish a mail session with the receiving mail server, your own
sending mail server immediately sends you a new e-mail to your mailbox
telling you it couldn't get to the other end.

If you don't get an NDR (non-delivery report) e-mail back from the
receiving or sending mail server, either your sending mail server never
sent the e-mail or all the handshaking proceeded okay to get the e-mail
delivered. However, once the receiving mail server accepts the e-mail
(which means the sending mail server is off the hook), server-side spam
filtering or server-side rules on the recipient's mailbox, spam programs
on the recipient's host, or rules in the recipient's e-mail client can
all attribute to the blocking of delivery of that e-mail to the actual
recipient -- none of which is the fault of any of the mail servers
involved as they did their job.

If you don't get an NDR, your e-mail got to the recipient's mail server
or your sending mail server never sent it (and never told you). E-mail
delivery is not guaranteed but rarely does something between the mail
servers interfere with its delivery. The mail servers don't need to
provide both negative and positive feedback. Just negative feedback is
sufficient. Since few mail servers bother with delivery receipts, don't
waste time trying to use them. They're busy enough with their real work
to waste resources on superfluous status traffic.
 
V

VanguardLH

VanguardLH said:
It is rare that a mail server wastes its time sending delivery receipts
(which the mail server handles versus read receipts which the e-mail
client handles). After all, they already send back negative feedback if
they cannot deliver an e-mail. The lack of negative feedback is the
positive feedback you want.

If you throw a ball out the window, do you need a "window guard" to hand
you a receipt showing the ball went out the window? No. The ball
bouncing off the wall around the window and bobbling about your side of
the window (negative feedback) is all you need to know that it did not
get through the window. That absence of a ball bouncing back (lack of
negative feedback) tells you it went through the window.

Normally the receiving mail server will reject an e-mail during the mail
session with the sending mail server if it finds the e-mail cannot be
delivered. If the receiving mail server accepts the e-mail during a
mail session but later finds out it is undeliverable, it sends back a
new e-mail to the sender (professed in the return-path headers) saying
the e-mail could not be delivered. If your sending mail server cannot
establish a mail session with the receiving mail server, your own
sending mail server immediately sends you a new e-mail to your mailbox
telling you it couldn't get to the other end.

If you don't get an NDR (non-delivery report) e-mail back from the
receiving or sending mail server, either your sending mail server never
sent the e-mail or all the handshaking proceeded okay to get the e-mail
delivered. However, once the receiving mail server accepts the e-mail
(which means the sending mail server is off the hook), server-side spam
filtering or server-side rules on the recipient's mailbox, spam programs
on the recipient's host, or rules in the recipient's e-mail client can
all attribute to the blocking of delivery of that e-mail to the actual
recipient -- none of which is the fault of any of the mail servers
involved as they did their job.

If you don't get an NDR, your e-mail got to the recipient's mail server
or your sending mail server never sent it (and never told you). E-mail
delivery is not guaranteed but rarely does something between the mail
servers interfere with its delivery. The mail servers don't need to
provide both negative and positive feedback. Just negative feedback is
sufficient. Since few mail servers bother with delivery receipts, don't
waste time trying to use them. They're busy enough with their real work
to waste resources on superfluous status traffic.

To clarify:

- Mail servers rarely *respond* to delivery receipt requests.

- Mail servers do not /reject/ e-mails because a delivery notification
header (for delivery receipt or read receipt) was used inside the
e-mail.

- Spam filters or rules may block e-mails that contain delivery
notification headers. Spam filters or rules can be server- or
client-side functions.
 
B

Brian Tillman [MVP - Outlook]

Thanks. Is it common for mail servers to not accept messages with delivery
receipts requests? Why would a server be set up that way?

I don't think it's common for a server to disregard messages containing
delivery receipt requests, but I can't thgink of many other explanations for
what you describe. It is common, however, for servers to disregard the
request but accept the message.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top