"Lanwench [MVP - Exchange]"
Yes, unless it's been disabled (and that just applies to Internet
mail)
As far as I know, when you disable read receipts in OL2003, it
actually
blocks all - Internet & Internal. I am the only user on my Exchange
server
at the moment so I can't test here or now - but I've read plenty of
posts
that indicate that disabling read receipts in Outlook disables all of
them.
To the OP:
Even getting a read receipt doesn't really prove anything and I don't
like
or use them anyway.
Send your important e-mails to Exchange/Active Directory groups, so
you can
prove that as a member of the group, Joe Bloggs was sent *exactly*
what
everyone else was sent, at that date & time.
If you have OL2003 and are using cached mode, check for sync errors on
the
client. Have them check in OWA as well, too.
Also check any junkmail filters. If your employees didn't tell fibs
before,
why would they start now?
The e-mail that contains a read receipt request (i.e., it has the
"Disposition-Notification-To:" header) is handled by the MUA (mail user
agent), according to RFC 3798.
Disposition-Notification-To Header
A request for the receiving user agent to issue message disposition
notifications
That means Outlook or whatever is the e-mail client handles the e-mail
and decides whether or not to send a reply. The delivery reciept is
handled by the mail server before it is even added to the destination
mailbox. All the delivery receipt does is tell you that your e-mail was
accepted by that mail server, but then *not* getting an NDR
(non-delivery report) would do the same thing except that the NDR could
possibly get lost. The delivery receipt does not tell you the recipient
read your e-mail. Getting reactive or positive feedback for mail
delivery is preferrable than waiting for the lack of negative feedback.
However, many mail servers will ingore delivery receipt requests.
Read receipts are handled by adding a header to the message. The MUAs
add the header and decided whether or not to respond to it. Delivery
receipts are notifications passed between the mail servers as they are
handled as extensions to SMTP commands sent between the mail servers.
The recipient doesn't have to reply to a read receipt request in an
e-mail, so you don't know if the lack of a read receipt is because they
didn't read it or because they choose not to reply. Delivery receipts
only work if the receiving mail server is configured to respond to them
but, in my experience, not many mail servers bother with the overhead of
handling delivery notifications but instead choose the lesser overhead
of sending an NDR if delivery fails.
There are other tricks in trying to determine that the recipient got
your message. One is to use web bugs and something spammers used for
awhile. MsgTag uses web bugs but it only works for HTML-formatted
e-mails and only if the recipient actually renders the HTML code rather
than reading in plain-text mode or uses anti-spam software that strips
out linked images. E-mail delivery is not guaranteed. If you need to
ensure that a recipient got your message, have them reply. If you get
no reply then you need to schedule a follow-up to prod them again for a
reply. When I needed to get replies from several departments for the
release of a new version of a product, I used read receipts, delivery
receipts, and web bugs but none were 100% reliable so follow-ups were a
requirement to get everyone to OK the release and get it out in time.
If they didn't respond to the follow-up e-mail prodding them to reply, I
had to call them and sometimes walk over and force them to compose an
e-mail (since I used them to track the okays). Once we wrote a policy
regarding the procedure and requirements for okaying the release of a
product, they were more likely to respond because any delays in the
release were their fault and documented to be due to their lack of
response. Yet there still sometimes you had to physically go to their
office and kick their butt.
