in message
i've really strange problem here. One of my customer (about 400
clients) complain that since we started migration from office 2000
to
office 2003 few users (less than 10) are having some problems with
the
outlook read receipts. Users are using outlook 2003 and can't
receive
the receipts for some groups of users, for example one is
complaining
she can't receive the receipts from all people starting with letter
"g". The same user can change pc, and all works fine, so it can't be
a
problem of who receive the email.
Do you push policies that enforce all your employees to respond to
read receipt *requests*? Do any of those employees have domain admin
privileges on their own host so they could override any policies that
you push at them (so you push the policy when they login but they use
a shortcut or scheduled event to run a .reg file that undoes those
policies put into the registry)? Besides trying to push a policy to
enable automatic read receipts (which hopefully your Exchange server
will filter out of externally received e-mails), do you actually have
a company policy that requires its employees to enable automatic read
receipts?
Are any of these users running unathorized software on their hosts?
Do you actually have a client that lets you take inventory to know if
they are running unauthorized software? Maybe some of them have
installed anti-spam or anti-malware software that filters their
outbound e-mails to remove the read receipt header or do the same on
inbound e-mails. For example, at home, I use SpamPal with its
HTML-Modify plug-in which lets me delete the headers from inbound
e-mails regarding delivery notification (i.e., read receipts).
Although I have Outlook configured to never respond to read receipt
requests, I also have this anti-spam plug-in eliminate those headers
before they are delivered to any e-mail client that uses SpamPal for
spam filtering.
For the recipients that are getting the e-mails for which a read
receipt is requested, have them check the headers to see if any of the
following are listed:
Read-Receipt-To
Return-Receipt-To
Return-Receipt-Requested
Disposition-Notification-To
Generate-Delivery-Report
Some are for delivery notification (the mail server is supposed to
respond that it accepted the e-mail for a valid account), some are for
read notification (the recipient's e-mail client is supposed to
acknowledge the message if and when the message was actually viewed).
I don't remember which header is for which function. If none of those
headers are present, the recipient won't be sending back a receipt
when they view that message. Outlook doesn't record when it sends
read receipts so the recipient won't know if they sent any.
Outlook has had a long history of having read receipt e-mails get
stuck when sent. They won't appear in the Outbox folder in the
message store; i.e., they are hidden items. When they get stuck, you
have to use something like OutlookSpy or Microsoft's MDBVU32 to edit
and fix the message store, a rather daunting task for those not
intimate with the .pst database file (but then you are probably using
Exchange so it is unknown if your users are keeping a local offline
copy in a .pst file). Often those that request read receipts are
doing it trivially. Rather than using read receipts to prove (which
is inaccurate) that a recipient read a message, have the sender
request a reply when and *IF* a reply is needed. Obviously this does
not apply when meeting requests are sent (which I don't know would
ever bother trying to use read receipts to acknowledge acceptance of a
meeting request).
The receipt only claims that the recipient opened the message to view
it but there are other reasons why a message might've been opened but
not because the user actually read it, so you cannot use the receipt
as a guarantee that the user read their e-mail. You need to have a
company policy that says it employees are responsible for any content
of internal e-mails. Doesn't matter if they did not read it. They
are still responsible for any actions that were required by them based
on the e-mail. That is, they are still required to do their job if
that job entails actions based on e-mailed messages. Internal e-mails
must be viewed equivalent to phone calls. Employees aren't allowed to
not answer their internal phone calls, either, or lift the handset and
then immediately hangup.
Automatically sent read receipts do not prove the recipient actually
read an e-mail. The option would have to be configured to prompt the
recipient to send the read receipt but most e-mail users don't want to
bother answering all those prompts, especially if it is a pervasive
policy at a company to always request the receipts. Would you want to
get interrupted with a popup prompt and have to say Yes to denote that
you acknowledge that you actually read an e-mail? If you configure
Outlook to automatically send a read receipt, there is no proof at the
sender's end that the user actually read the message. With 3rd party
software interrogating the e-mails, it is possible the message got
"opened" without the recipient ever reading it. The recipient may
have simply been using the arrow keys to move between the messages,
moved past your message, it got opened in the Preview pane, a read
receipt gets sent, but the recipient never read it but was instead
navigating to another message that they did read. Read receipts are a
poor concept at proving that anyone actually read your e-mail.
Automatically sending read receipts proves nothing about having read
your message. No user is going to bother with constant prompts to
answer Yes to send them. Most users are inclined to always ignore the
request. Anti-spam programs may strip out some headers, like delivery
notification, priority, X-headers for upstream anti-spam filters, etc.
You need to check if the recipient gets e-mails that includes the
delivery notification headers. You also need to ensure that they or a
mail hop between doesn't alter the content of that e-mail and its
headers. You also need to check spam/junk filtering to see if the
senders aren't maybe discarding the read receipts that they themselves
had requested.
