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:this is cool

[quelrods]

woops forgot to add it's direction finding skills are weak. Apparantly I'm in Michigan? I'm in Austin,TX and my POP is chicago. It appears to try to get information via one of the upstream links which is horribly inaccurate.

Re:Single pixel gif?

[Neon Spiral Injector]

I just tested, they send an image/jpeg with a header not specifying the length at 1 byte/second. But it is only 302 bytes long, so they can't track for more than 5 minutes. It is a real JPEG, 1x1 pixels, created with an Adobe product.

Re:How it 'works'

[orthogonal]

So not only will it not work in text-based email clients (such as mutt), it won't work in modern versions of Outlook which block inline images by default

Let's be even more sensible: your firewall rules should allow your email client to make connections to your mail server ONLY, and only to its ports 110 and 25 (I'm assuming POP3; IMAP would be other orts).

(Not for linux users: Microsoft Windows firewalls typically allow setting rules separately for separate applications, by associating a process name (and in serious firewalls, the executable's MD5 sum) with the process requesting the connection.)

This takes care of all web bugs, inline images, and javascript pop-ups or Active-x in Microsoft HTML email.

Note that with any sensible email client, this won't block html links, as clicking an html link should invoke a separate browser application, with its own firewall rules.

It will block linked (not inline) images, but only a very small minority of email linked images that are at all useful to view -- in this case I just save the email as html and open in a web browser.

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.

Re:fp!

[senatorpjt]

OK, so, who's going to set up a free service that duplicates what DidTheyReadIt does. It uses almost no bandwidth (you're only loading a 1x1 pixel image off a webserver). I'd do it if I had any hosting capability whatsoever.

The entire point of a free service would be 1) to educate people as to why this is pointless and 2) to make it unprofitable and drive these people out of business.

Heard about this on NPR interview last week

[kc8jhs]

The shocking thing was, in the interview, the founder/inventor(not)/designer/coder whatever he was, claimed that large large portions of mail actually gets lost on the internet.

A gentleman called in from a design engineering firm who emails large documents to other members of the firm and other associates around the country. The "expert" insisted that the didtheyreadit.com was the perfect service for them to assure that their emails made it there and were in fact read.

My question was this, how does email between two people who regularly email each other, and are probably expecting it, "get lost"? This was a major point that the guy was making, which seemed to me like he was spreading classic FUD.

Lets make sure that our friends aren't using this product for those reasons! Assure them that undeliverable mail will be properly reported back to them always, and show them how to set their mail clients to always accept mail from those in their address books!

-Mikey P

Re:How it 'works'

[ip_fired]

There is a problem with SpamAssassin in that you can get around the little web-bug feature with a little setup on the server side. If the spammer were smart, they would use mod_rewrite to change the url from:

http://spammerserver.com/cgi-bin/redirect.pl?id= [m d5sum]

to:

http://spammerserver.com/images/[md5sum]/image.j pg

Apache then takes the a out of the url, rewrites it, and redirects it to a script which then records the hit from the user and notes that this address is valid.

Spam filters out there need to find a good way of detecting unique identifiers that can be used to track a user.

I'm personally moving towards the scorched earth method with my personal e-mail account. Blcok everything that isn't on my whitelist. If I know you, you're on my whitelist. It's certainly not the best method, but I hate spam.

Here's How They Time the View

[jzap]

They put a 1x1 image in the HTML e-mail with a (long) unique number in the SRC URL. The unique number identifies the sent message. When your e-mail client tries to fetch the image, they send the header right away (type=image/jpeg), but they trickle the data to you at one byte per second. This keeps the connection open for as long as you view the message. When you stop viewing the message, the connection closes, and their timer stops.

I'd show you what a dump of an 118-byte-long version of their JPEG image looks like, but the Slashdot Lameness Filter didn't like all those "junk" characters! However, you can view the dump here: http://jzap.com/img/ReadItBug.jpeg.txt