Several sites I review have mentioned a new “service” offered at DidTheyReadIt.com. Basically, these folks purport to offer a plan wherein the sender of an email can know, absolutely, 98% of the time, whether or not their email has arrived, if it’s been read, for how long, and where (geographically) the recipient is.

Sounds both compelling and a bit scary, doesn’t it? Well, here’s something else it is: BULLSHIT.

Now that’s a technical term, you understand, so let me break it down for you; I’d hoped a skeptical press would have done this for us, but the coverage so far has been fawning and utterly naive. Shouldn’t journalism — particularly technology journalism — involve more than quoting q press release?

Anyway, what they’re talking about is universal return-receipts. Closed email systems have offered these for years, which is why you can click “request receipt” in Outlook when you’re sending mail to Sally down the hall in Accounting. Even then, though, Sally (usually) has the option to cancel your return-receipt request. The important point, though, is that this works only in a homogenous system — i.e., where everyone uses the same email program — because there’s no universal way to request a return receipt. To make it work, requesting mail clients must add “headers” telling the receiving program that they want one, and the receiving program must understand those headers AND comply with the request.

This works fine when everyone uses the same program, and can even work for mail sent over Internet because the mail transfer mechanism of the Net doesn’t actually pay much attention to the message en route, so programs can add all sorts of information to the message without interfereing with its ability to get from A to B; a return-receipt request is just one example.

But what happens if you send mail requesting a return receipt to a person who doesn’t use a mail program that understands (or cares about) Outlook’s special headers? Nothing. They’re ignored. Put simply, to make universal return-receipt work, you’d have to create a universal return-receipt header standard, and then get every mail client to play along, which will never happen for a whole host of reasons.

So how are these folks doing it? Well, they’re not. They’re relying on a technique used widely by spammers to measure the rate at which a given piece of spam has been read. It’s not a terribly robust method, and it’s particularly poorly suited to this problem. The sender (or DTRI, in this case) adds a link to a particular image to the mail in question, and then waits for the web server to register a hit. A web request includes an IP, which can then be used to determine location (though only with very sloppy accuracy; if I dial in from Hawaii using an ISP in New York, it’ll show me in Manhattan — and at last count everyone on AOL looks like they’re in Reston, Virginia).

By configuring the web server’s handling of these images carefully, they can force a refresh every so often, and get a fairly inaccurate read for how long the mail was open. All in all, it’s terribly sloppy, and almost guaranteed to fail.

The core problem, though, is that for DTRI’s method to work, you must read your mail in HTML, which is by no means universal; we all know that Sally down the hall loves to send green-on-pink mail with a flower border, and frankly we’re sick of it. Fortunately, most mail programs can be configured to display the plaintext alternative (if there is one), or to ignore the bulk of the formatting, and it doesn’t take too many of Sally’s Happy-Hour messages to send us to this particular preferences menu.

Aside from that, though, there’s the issue of the image itself. Images can come with emails one of two ways: they can be included in the mail itself (which makes the mail huge), or they can be linked to images stored on a web server somewhere, which is what DTRI does. This is the real dealbreaker: even particularly promiscuous, insecure clients like Outlook no longer load non-embedded email images by default. It only takes one super-graphic porn spam to send most folks to that particular setting, in any case. Add to this the fact that its use by spammers makes a mail with such a link look like spam to automated filters, and you begin to see the problem.

Yup. That’s it; for this, DidTheyReadIt.com wants fifty bucks a year. I’ve got a better idea: if it’s really that important that you know if someone read a given communique, send it by registered mail. Not email; use the paper kind. It’s good for shit like this. Email is — and probably always will be — essentially asynchronous. Accept it. And don’t be taken in by charlatans like the folks at DidTheyReadIt.

(So why does this method work for spammers, or does it? I’d say it probably does, because they’re measuring something else. DTRI wants to measure individual mails, but a spammer just wants to know if some of his mail got through the increasingly-elaborate filter gauntlet. He can afford to assume that only a small percentage of those who read his mail loaded the image, and extrapolate a more accurate “read rate” based on his hits. For obvious reasons, this is worthless to DTRI.)

More
A little surfing led me to a couple other services purporting to offer precisely the same service: ReadNotify.com and MessageTag.com. Neither of these will work any better than DidTheyReadIt.com; all the information above applies to them, too.

Also, it looks like ZDNet actually has reasonable coverage, referring to the web bug technique as dead technology. Heh.