Testing didtheyreadit.com's Mail-Tracking Claims 400
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.
Re:this is cool (Score:5, Interesting)
Re:Uh, the link is wrong (Score:2, Interesting)
Re:Single pixel gif? (Score:2, Interesting)
Could be useful (Score:3, Interesting)
Re:Single pixel gif? (Score:5, Interesting)
Re:Uh, the link is wrong (Score:2, Interesting)
You know that a URL like
Re:How it 'works' (Score:1, Interesting)
Bollocks. Complete and utter bollocks.
Neither you or the moderator who considered this to be insightful have any idea what you're talking about; you clearly were taken in by their marketing material.
When you tack their domain onto the end of the recipient's address the email is delivered to their servers. This allows them to tack on whatever insidious webbug they want to the email, and possibly mine your email for marketing information while they are at it.
The email is then delivered onto the recipient's mailserver, just as if you had sent it directly.
Once it accepts it, they have absolutely no fucking way of knowing what that mailserver does with it. When the user downloads it, they will not receive any special gilt-edged notification of the event which you would normally be denied.
The only trick they rely on is the images thing.
Any claims otherwise are complete and utter lies.
In case I wasn't clear enough, bollocks.
Re:DNS fun... (Score:2, Interesting)
Re:How it 'works' (Score:5, Interesting)
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.
Paranoid Annoying Emailers (Score:3, Interesting)
At work, I am somewhat compelled to use outlook. Here's my favorite setting:
1) Automatically unflag incoming messages:
-Think noone reads your email? Why not flag every message you send. That way, they'll all look importat... or, the important ones will get lost in the see of red flags.
Do any of you have settings that would be good in Outlook?
Re:How it 'works' (Score:3, Interesting)
Mozilla-Thunderbird needs to make their version more like Evolution's, which has the option of allowing inline images from addresses you have put into your address book.
Re:How it 'works' (Score:5, Interesting)
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' (Score:5, Interesting)
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:Picture of Alex Rampell? (Score:3, Interesting)
A multi-talented family? Accountants, Software, [rampellsoft.com] and now a web-based business.
The software seems to be keyloggers and others.
Re:How it 'works' (Score:3, Interesting)
I give them credit for the "idea" and definitely the implemention (adding ".didtheyreadit" to the end of a standard email address), so best of luck to them.
And they certainly have achieved fantastic press with this slashdot exposure: suddenly a large group of people know the name, what it does, how it works and how much it costs...
Re:How it 'works' (Score:3, Interesting)
Re:fp! (Score:3, Interesting)
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 (Score:3, Interesting)
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
Whoops - the marketing SPAM backfired... (Score:2, Interesting)
Well, turns out that Ricardo had a 'setting' wrong on his mail server, or whatever, as my response to him was also broadcast to his entire spam list.
- He neglected to supress the recipient list.
- 'customers@batista.org' was aliased to his customer list.
- He allow any non-local reply to take advantage of that.
As confirmation, Ricardo sent me an e-mail pointing out *my* mistake in replaying 'all', and the subsequent deluge of 'bounced mails' and other recipients responding pretty much corroborated this.
Whoops.
Granted, this is a simple mistake that could happen to anyone (well, not really) but doesn't paint to rosy a picture of someone claiming to provide an expert e-mail service.
I have no idea why someone like Ricardo Batista would jump on doing something so obviously silly and transparently flawed (I guess rent needs paying), but I wonder how mnay (if any) people will fall for this.
Harry
Re:How it 'works' (Score:2, Interesting)
So do your part! Enter false information into their database as much as possible! Fill in invalid e-mails on those little "raffle" tickets that you see trying to raffle off a car in the mall. Make sure it's an AOL account or something that delays sending back an error response instead of the instant error notifaction that some mail providers give. That way they have to worry about parsing the e-mail. Perhaps to make it even easier, maybe AOL could start sending randomized text back in their error messages to confuse the spammer's parsers.
Re:How it 'works' (Score:4, Interesting)
http://spammerserver.com/cgi-bin/redirect.pl?id
to:
http://spammerserver.com/images/[md5sum]/image.
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.
Re:DNS fun... (Score:3, Interesting)
Ok, a little more digging. mail.cluster1.didtheyreadit.com resolves to 3 consecutive ip addresses. Repeat the process for www.didtheyreadit.com and you find that the same 3 ip address resolve to that. This smells a lot like somebody has gone to the effort to build a high availability cluster for dealing with mail, just based on the consecutive ip's and the telltale names.
Interesting, this same cluster is also set up to provide the backing infrastructure to do email tracking via embedded images.
Obviously these guys are set up to handle volume, so, that does prompt a question. Are there really enough people using this service to load up 3 mail servers in a cluster configuration ? Or is it possible they have the infrastructure in place for another business, and they are leveraging it to do this too ?
I just dont see the 'didtheyreadthat.com' business being large enough to swamp 3 machines processing the outgoing mail, and the incoming image connections. But, if this is just a sideline for machines that are spending the day tracking inline images on spam, it sure makes sense. A whole new business leveraged off existing infrastructure.
Re:DNS fun... (Score:3, Interesting)
The first is that Internet mail has retry functionality built in. If your mail server goes off-line for a few minutes, most clients won't notice. It's not an immediate service like HTTP. Personally, I only have a backup MX for my personal domain because my box is physically located at my employer's office. The company could unplug it (permanently!) at any moment. People I trust - companies not one iota.
The other thing is, as other people have mentioned, this service relies on embedded 1-byte images retrieved by mail clients using HTTP. In this case, if their HTTP servers are off-line, the service is basically non-functional. In this case, having the MX delivery fail may actually be a feature. If the MX fails at the same time as the web server, you avoid having mail delivered when it can't be tracked.
Incidentally, this side-effect of having related service failures is one reason I think that the DNS requirements of having DNS servers available in multiple networks is probably bogus for many services. For a lot of companies, if you HTTP server is off line, why would you care that DNS is working? Why would you spend any time or money making your DNS more reliable than your web service? (My guess is that DNS weenies consider reliable DNS an end, rather than a means.)
Simple! (Score:2, Interesting)
Re:How it 'works' (Score:3, Interesting)
Open a Terminal...
defaults write com.apple.mail PreferPlainText -bool TRUE
Voila, any stupid HTML email will be displayed as text only.
Here's How They Time the View (Score:3, Interesting)
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 [jzap.com]
Re:Well... at least no false positives. (Score:3, Interesting)