DVation191
asked on
Read Receipt Alternatives
The problem with read receipts is that people have the option to not have one sent. I have domain admin privelages and I could force the option, but I don't want it to be forced. Instead, I am looking for an alternative way of verifying an email has been read (or at least opened).
One possible solution I thought of is a spammer's technique of embedding an image in an email. When the image is loaded they know your email address is legit. Is there something out there that would let me do something similar on a much smaller scale? (about 50 employees). Any ideas?
One possible solution I thought of is a spammer's technique of embedding an image in an email. When the image is loaded they know your email address is legit. Is there something out there that would let me do something similar on a much smaller scale? (about 50 employees). Any ideas?
ASKER
Because I don't know of any way to distinguish forcing the return of a read receipt internally. I don't want them to have to respond with a read receipt that were requested externally unless they want to.
This is in an Exchange environment?
ASKER
Yes, exchange 2000
DVation191,
I'm not near an Exchange server at the moment, so I can't verify what I'm about to say. With that in mind, I believe there's a setting in Exchange that can control whether receipts go to the internet or not. If I'm right about that, then you could use a policy to enforce receipts and use the Exchange setting to prevent them from going to the internet. If that doesn't sound like a good solution, or if I'm wrong and there is no setting in Exchange for controlling this, then you could use the graphic solution you mentioned. Although with that I'm not sure how you're going to distinguish one message from another. Yet another alternative is to write an Outlook addin that handles this. You'd have to install it on each user's computer and then lock their environment down so they couldn't change it or turn it off.
I'm not near an Exchange server at the moment, so I can't verify what I'm about to say. With that in mind, I believe there's a setting in Exchange that can control whether receipts go to the internet or not. If I'm right about that, then you could use a policy to enforce receipts and use the Exchange setting to prevent them from going to the internet. If that doesn't sound like a good solution, or if I'm wrong and there is no setting in Exchange for controlling this, then you could use the graphic solution you mentioned. Although with that I'm not sure how you're going to distinguish one message from another. Yet another alternative is to write an Outlook addin that handles this. You'd have to install it on each user's computer and then lock their environment down so they couldn't change it or turn it off.
ASKER
BlueDevilFan,
That is true...and I am aware of the ability to block read receipts externally. The problem is, I *want* them to be able to go to the outside (with the employees permission, of course). That is why I need an alternative to Outlooks "read receipt" system. I'm surprised I haven't had any suggestions so far.
That is true...and I am aware of the ability to block read receipts externally. The problem is, I *want* them to be able to go to the outside (with the employees permission, of course). That is why I need an alternative to Outlooks "read receipt" system. I'm surprised I haven't had any suggestions so far.
DVation191,
I understand. I don't see any options beyone what I've already mentioned. For this to work properly there has to be some intelligence at the user's end. The graphic thing won't work like a receipt because it will fire every time the user opened the message and unless you had a separate graphic for each message you wouldn't know which message they opened. Outlook won't allow any kind of script in a message, so you can't place code in the body of the message that would fire when the message opened. Even if you could you'd suffer from the same problem as the graphic in that it'd fire every time the person opened the message. A macro would work, but the user could disable it easy enough. Unless there's a policy I'm forgetting about that would lock down their ability to get to macros. If you have administrative rights and some programming skill, then you could write a service that'd do this and install it on their computers quietly. If they don't have admin rights on their computers then I don't think they'd be able to stop the service. This approach would require a third-party utility though to get around Outlook's built-in security. Even then a clever user could circumvent this by telling Outlook to work off-line, capturing the receipts in the Outbox and deleting them.
I understand. I don't see any options beyone what I've already mentioned. For this to work properly there has to be some intelligence at the user's end. The graphic thing won't work like a receipt because it will fire every time the user opened the message and unless you had a separate graphic for each message you wouldn't know which message they opened. Outlook won't allow any kind of script in a message, so you can't place code in the body of the message that would fire when the message opened. Even if you could you'd suffer from the same problem as the graphic in that it'd fire every time the person opened the message. A macro would work, but the user could disable it easy enough. Unless there's a policy I'm forgetting about that would lock down their ability to get to macros. If you have administrative rights and some programming skill, then you could write a service that'd do this and install it on their computers quietly. If they don't have admin rights on their computers then I don't think they'd be able to stop the service. This approach would require a third-party utility though to get around Outlook's built-in security. Even then a clever user could circumvent this by telling Outlook to work off-line, capturing the receipts in the Outbox and deleting them.
ASKER
"The graphic thing won't work like a receipt because it will fire every time the user opened the message and unless you had a separate graphic for each message you wouldn't know which message they opened."
Web Bugs do this by using a script with the users email address in it to download an image in the mail (or web page) they are viewing. That's how I'd know it was opened.
"Outlook won't allow any kind of script in a message, so you can't place code in the body of the message that would fire when the message opened."
It's simple HTML that allows this, and Outlook is capable of reading HTML email.
" Even if you could you'd suffer from the same problem as the graphic in that it'd fire every time the person opened the message."
I'm okay with that. Since I'm sure anyone that implemented something like this already thought of that, I'm sure subsequent mail openings would be ignored. Even if they weren't, I'd be okay with that.
"If you have administrative rights and some programming skill, then you could write a service that'd do this and install it on their computers quietly."
I have the rights, not the programming ability. Hence, my EE question :)
"Even then a clever user could circumvent this by telling Outlook to work off-line, capturing the receipts in the Outbox and deleting them. "
That's a risk I'd be willing to take. I don't know any users here that would know or even care to figure out how to do that anyway.
Web Bugs do this by using a script with the users email address in it to download an image in the mail (or web page) they are viewing. That's how I'd know it was opened.
"Outlook won't allow any kind of script in a message, so you can't place code in the body of the message that would fire when the message opened."
It's simple HTML that allows this, and Outlook is capable of reading HTML email.
" Even if you could you'd suffer from the same problem as the graphic in that it'd fire every time the person opened the message."
I'm okay with that. Since I'm sure anyone that implemented something like this already thought of that, I'm sure subsequent mail openings would be ignored. Even if they weren't, I'd be okay with that.
"If you have administrative rights and some programming skill, then you could write a service that'd do this and install it on their computers quietly."
I have the rights, not the programming ability. Hence, my EE question :)
"Even then a clever user could circumvent this by telling Outlook to work off-line, capturing the receipts in the Outbox and deleting them. "
That's a risk I'd be willing to take. I don't know any users here that would know or even care to figure out how to do that anyway.
ASKER
Here is a good example of what I want to do:
http://www.nthelp.com/OEtest/oe.htm
While it works great, they don't tell you how to implement it yourself.
http://www.nthelp.com/OEtest/oe.htm
While it works great, they don't tell you how to implement it yourself.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
" First, every message you send is going to have to be in HTML format. "
Not true, only the emails that I want to verify are being opened will need to be in HTML
"Second, how are you going to insert the image tag? "
There are plenty of ways ... http://www.slipstick.com/mail1/html.htm
"Third, you're going to have to add parameters to the image tag uniquely identifying the message and the recipient. "
I don't really see that as a problem considering the frequency I actually plan on doing this...1 or 2 emails a week at the most.
"Fourth, forget about using distribution lists."
True. Except that in the web logs I can at least verify by IP...more tedious, sure, but doable.
" Fifth, don't forget to insert the image tag in every message you want a receipt for. "
I think that goes without saying :)
"Sixth, to see the results you'd have to read through the server's web log. "
Also, not a problem.
http://www.microsoft.com/technet/scriptcenter/tools/logparser/default.mspx
"Seventh, this approach is easily defeated. Microsoft recognizes the potential threat and had added a configuration option to control the downloading of images."
True, but I can use Group Policy to add my domain to the "safe senders" list and Outlook will not block the image. The policy is in the Office 2003 ADM template.
"Another way to defeat it is to set Outlook to read all message in plain text format."
Nobody has Outlook set up that way in my organization...so this is also not an issue.
"The code would have to detect when a user is logged in, connect to Outlook when they are, trap message opening events, test to see if the item is requesting a receipt, determine whether the sender is internal, and send a receipt as needed."
Really, the only thing I can think of that would make this easier would be to configure the web log parser to somehow be able to only parse the outlook requests. Otherwise, seems rather simple to me.
Not true, only the emails that I want to verify are being opened will need to be in HTML
"Second, how are you going to insert the image tag? "
There are plenty of ways ... http://www.slipstick.com/mail1/html.htm
"Third, you're going to have to add parameters to the image tag uniquely identifying the message and the recipient. "
I don't really see that as a problem considering the frequency I actually plan on doing this...1 or 2 emails a week at the most.
"Fourth, forget about using distribution lists."
True. Except that in the web logs I can at least verify by IP...more tedious, sure, but doable.
" Fifth, don't forget to insert the image tag in every message you want a receipt for. "
I think that goes without saying :)
"Sixth, to see the results you'd have to read through the server's web log. "
Also, not a problem.
http://www.microsoft.com/technet/scriptcenter/tools/logparser/default.mspx
"Seventh, this approach is easily defeated. Microsoft recognizes the potential threat and had added a configuration option to control the downloading of images."
True, but I can use Group Policy to add my domain to the "safe senders" list and Outlook will not block the image. The policy is in the Office 2003 ADM template.
"Another way to defeat it is to set Outlook to read all message in plain text format."
Nobody has Outlook set up that way in my organization...so this is also not an issue.
"The code would have to detect when a user is logged in, connect to Outlook when they are, trap message opening events, test to see if the item is requesting a receipt, determine whether the sender is internal, and send a receipt as needed."
Really, the only thing I can think of that would make this easier would be to configure the web log parser to somehow be able to only parse the outlook requests. Otherwise, seems rather simple to me.
>" First, every message you send is going to have to be in HTML format. "
> Not true, only the emails that I want to verify are being opened will need to be in HTML
Which is what I meant. Every message that you want a receipt for.
> "Second, how are you going to insert the image tag? "
> There are plenty of ways ... http://www.slipstick.com/mail1/html.htm
I know it's possible to insert an image tag, my point was that it's not as straightforward as checking a box to indicate you want a receipt. It's extra steps, easily forgotten, and any mistake in the image tag will result in no receipt.
> "Fourth, forget about using distribution lists."
> True. Except that in the web logs I can at least verify by IP...more tedious, sure, but doable.
Definitely doable as long as you're willing to take the time to go through the logs.
> "Another way to defeat it is to set Outlook to read all message in plain text format."
> Nobody has Outlook set up that way in my organization...so this is also not an issue.
But they could switch to that any time they wanted to avoid generating a receipt.
> "The code would have to detect when a user is logged in, connect to Outlook when they are, trap message opening events, test to see > if the item is requesting a receipt, determine whether the sender is internal, and send a receipt as needed."
> Really, the only thing I can think of that would make this easier would be to configure the web log parser to somehow be able to only > parse the outlook requests. Otherwise, seems rather simple to me.
I was talking about the service approach I'd mentioned, not this solution.
I'm not trying to disuade you from using this, I just wanted to point out what I see as flaws so you can make an informed decision. If this approach works for you, then my advice is to run with it. You can make the log parsing a bit easier by looking for a web log parsing tool. There should be some on any number of shareware web sites.
> Not true, only the emails that I want to verify are being opened will need to be in HTML
Which is what I meant. Every message that you want a receipt for.
> "Second, how are you going to insert the image tag? "
> There are plenty of ways ... http://www.slipstick.com/mail1/html.htm
I know it's possible to insert an image tag, my point was that it's not as straightforward as checking a box to indicate you want a receipt. It's extra steps, easily forgotten, and any mistake in the image tag will result in no receipt.
> "Fourth, forget about using distribution lists."
> True. Except that in the web logs I can at least verify by IP...more tedious, sure, but doable.
Definitely doable as long as you're willing to take the time to go through the logs.
> "Another way to defeat it is to set Outlook to read all message in plain text format."
> Nobody has Outlook set up that way in my organization...so this is also not an issue.
But they could switch to that any time they wanted to avoid generating a receipt.
> "The code would have to detect when a user is logged in, connect to Outlook when they are, trap message opening events, test to see > if the item is requesting a receipt, determine whether the sender is internal, and send a receipt as needed."
> Really, the only thing I can think of that would make this easier would be to configure the web log parser to somehow be able to only > parse the outlook requests. Otherwise, seems rather simple to me.
I was talking about the service approach I'd mentioned, not this solution.
I'm not trying to disuade you from using this, I just wanted to point out what I see as flaws so you can make an informed decision. If this approach works for you, then my advice is to run with it. You can make the log parsing a bit easier by looking for a web log parsing tool. There should be some on any number of shareware web sites.
ASKER
Ok great. Well I think I should be able to make this work thanks to your help.
Cool. Good luck.
is there any reason you want to devise a way of doing this rather than just force the issue?
Cheers!