Testing didtheyreadit.com's Mail-Tracking Claims

iosdaemon writes "didtheyreadit.com claims to be able to track your sent email: "When, exactly, your email was opened. How long your email remained opened. Where, geographically, your email was viewed. DidTheyReadIt works with every single internet provider and e-mail account, including EarthLink, AOL, NetZero, Juno, Netscape, Hotmail, Yahoo, and much more." Read on for more. "This appears to be snake oil. I put it to test just in case someone had come up with some magical code. I sent email from a Yahoo.com account through the service, to an account on a Linux Box. Running tcpdump, I received the email from my pop and let 5 minutes pass before opening it. I left the message open with the cursor in the text for another 5 minutes. Tcpdump revealed absolutely no questionable traffic. And, the service control panel indicated the email had not been viewed. Sending email to a Yahoo.com account results in a 'read' in the service CP. But I had the message open for 10 minutes, and it indicated a 2-minute read......"

The company's "How it works" page explains the system to some degree; it involves redirecting all mail to be tracked through their servers by appending "didtheyreadit.com" to your recipient's email address. I doubt this is mutt-compatible ... Reader xrxzzy points out USAToday's article on the service as well.

Comments

Re:How it 'works'

[ciggieposeur]

I found that browsers were cacheing them, so it wouldn't always register if it was viewed in a webmail acount.

PATENT ALERT

I am about to describe a patented technique. Seriously. If you ever think you're going to implement a web bug, do not read this or IBM will be able to sue you for treble damages.

Since a) I no longer work for IBM, and b) the method is on file in the patent, I am not violating my IP contract with IBM by describing this method.

.
.
.

PATENT ALERT

.
.
.

Method:

The way to defeat browser caching is to make the IMG SRC point to a CGI that returns a REDIRECT (302) that points to the single-pixel image. So you might have IMG SRC="server/path/to/cgi?key1=val1&key2=val2". The browser will have to tick the CGI because it has "dynamic" parameters. However, the CGI has to return a REDIRECT because an intelligent proxy server in the middle might be trying to cache the output too. You don't care if the single-pixel image itself is cached, you just want to capture the CGI hit with all the parameters.

Re:How it 'works'

[jonadab]

You're assuming he would prefer to view the message HTML-formatted rather than
in plaintext, which for most users who know the difference is not the case.

Viewing in plain text has the advantage of providing a consistent look and
feel for every message, always using the reader's preference for fonts and
colors, among other things. (There are a few exceptions, but most people
prefer the fonts and colors *they* like over the ones other people want them
to see, except in special circumstances such as when having a discussion
about fonts and colors.)

It's all moot for me; I use Gnus. Currently I have it set to only display
text/plain parts and show anything else as an attachment, which I can save
and view if I choose. This means HTML mail has the From and Subject fields
to convince me it's not spam. It's been years since I received an HTML
message that wasn't spam, incidentally, and I get a *lot* of mail. I do
sometimes receive multipart/alternative messages that aren't spam, but the
plain text part always shows fine in that case.

I *could* configure Gnus to display HTML parts, using W3, or to launch a
browser, such as Mozilla, but I choose not to configure it that way because
I prefer to view the plaintext alternative, and like I said it's been years
since I received an HTML-only message that wasn't unsolicited bulkmail.

Back to topic, the didtheygetit.com claim that the service works regardless
of what client the recipient uses is obviously not only bogus for their
specific product but in fact a totally impossible thing for any product to
deliver, unless the content is munged into a form that they are *unable*
to view without alerting you, such as an executable that unencrypts and
displays the text after phoning home -- but something like that would be so
odious to so many recipients that the sender would by using it be decreasing
significantly the chances that the message would be read at all, which would
rather defeat the purpose of the whole idea. In other words, it's an utterly
impossible thing to deliver. OTOH, they only claim it works in 98% of cases
and carefully qualify this saying "in our testing", which presumably means
they didn't test with geeks who use carefully selected high-quality mail
readers; they probably tested mostly with Outlook, two or three popular
webmail services, and maybe Eudora or Netscape. I can positively guarantee
that it would never work with Pegasus Mail (though pmail *does* support read
receipts, but only if the user has turned them on in the prefs; they're
off by default), and obviously it doesn't work with my particular config
of Gnus. (I don't know about a default Gnus config, but that's largely not
a significant issue since people who leave settings at their defaults don't
tend to use Gnus in the first place; it's very much geared toward people
who like to change lots of options.) Clearly it also wouldn't work with
mutt or pine or anything like that, and *obviously* it wouldn't work if
the user talks to the POP3 server directly (which I happen to have just
done yesterday, though I only looked at three or four messages that way,
and I'm atypical, being the maintainer of the Net::Server::POP3 module).

I can imagine that it might be useful to some people nonetheless, especially
in a largely homogenous corporate environment wherein it is predictable what
mail client everyone or almost everyone uses. But clearly they're very much
exaggerating (at best) when they claim it works irrespective of the client.