h a l f b a k e r y
You think: Aha! We go: ha, ha.
idea:
add, search, annotate, link, view, overview, recent, by name, best, random
meta:
news, help, about, links, report a problem
account:
Browse anonymously,
or get an account
and write.
or Create a new account.
|
|
| Please log in.
If you're not logged in,
you can see what this page
looks like, but you will
not be able to add anything.
| |
SMTP is a "best effort" protocol. It does it's best to deliver mail in a timely manner, but places more emphasis on fault tolerance than on speed. Spam filters exacerbate the problem. How do you know your e-mail didn't sit in the messaging queue on your outbound mail server for two days before it was delivered? |
|
| |
It's Ted Stevens all over again. |
|
| |
I am sure this is Baked for commercial spamware. Some certainly tracks when you look at the message (by embedding pixel jpgs). |
|
| |
[DrCurry] yup this has been dont a long time back in a more baked way...for example, ReadNotify.com .. tracks in all kinds of ways (you get to configure it) such as through embedded images. The service works well. |
|
| |
I have to challenge that 'baked' claim. |
|
| |
This idea is to track how long people take to respond to an email, not to track when they open it. That would mean measuring the timespan from when an original mail is sent to when a human written, not just 'return receipt', reply is received. |
|
| |
I'd imagine that it could perhaps use a 'time opened' measurement for those who additionally wanted know how long people spent between reading and replying, but regardless it will still suffer distortion from the queuing problem noted by [phoenix], for both the original and reply emails. However measuring over a sufficiently large number of correspondances might balance out the effect across contactees. |
|
| |
Quite how one would then use the findings is anyone's guess. I'd suggest posting a league table to all your friends and threaten the pisspoor performers with relegation. They'll all love you for it. |
|
| |