Email tracking and readnotify.com

In the process of looking for a way to implement open rate tracking in an in-house created HTML email system, I had a look at readnotify.com. Their web page claims to provide tracking for:

• Date and time opened – by using tracking images, etc.
• Location of recipient (per their ISP city /town) – by the IP address of the recipient’s mail server
• Map of location (available on paid subscriptions) – by the IP address of the recipient’s mail server
• Recipient’s IP address – by the IP address of the recipient’s mail server
• Apparent email address of opening (if available)
• Referrer details (i.e. if accessed via web mail, etc.) – by the receiving mail server headers
• URL clicks – by embedding tracking code into URLs
• How long the email was read for
• How many times your email was opened – by using tracking images
• If your email was forwarded, or opened on a different computer

That’s a lot of quality tracking that would keep marketeers happy. At least you would think so, since HP used their service in 2006 to bug a CNET reporter.

Without further ado, after a quick an easy sign-up procedure (during which you have to use the exact email address that dispatches marketing email), I received my trial fix of 25 free emails (or 2 weeks of use, whichever comes first) and got a test email sent out straight away.

In order to use readnotify.com (further referenced to as RN) services, one has to append .readnotify.com to their recipients’ email addresses. That ensures that the message, before hitting recipients’ mailboxes, is routed to RN’s server. The RN server identifies the sender by the email address (the one you have used to sign up – I’ll use account@rn.com as an example), processes the emails and resends them to the recipients with the following headers added on:

Resent-Date: Mon, 17 Dec 2007 09:11:05 GMT
Resent-Message-Id: <2007698711.7H8S5089795737@mx.mxsvr.com>
Resent-From: “account@rn.com” <account@rn.com.glsebkhjbseoivr.emsvr.com>

The rest of the email employs several tricks for message tracking, including header and HTML injection.

Header injection

1. Content-disposition header injection
This header makes sure that the email elements are displayed inline, i.e. automatically, instead of attachments. This, obviously, has a direct impact on the display of an invisible tracking image used in email tracking. It also applies to the whole multipart body part, not to the subparts individually (i.e. HTML and text).

More information about Content-disposition field in RFC2183:

Content-Disposition header field

Two common ways of presenting multipart electronic messages are as a main document with a list of separate attachments, and as a single document with the various parts expanded (displayed) inline. The display of an attachment is generally construed to require positive action on the part of the recipient, while inline message components are displayed automatically when the message is viewed. A mechanism is needed to allow the sender to transmit this sort of presentational information to the recipient; the Content-Disposition header provides this mechanism, allowing each component of a message to be tagged with an indication of its desired presentation semantics.

A bodypart should be marked `inline’ if it is intended to be displayed automatically upon display of the message. Inline bodyparts should be presented in the order in which they occur, subject to the normal semantics of multipart messages.

Reference: http://www.ietf.org/rfc/rfc2183.txt

2. Notice-Requested-Upon-Delivery-To (NRUDT) header injection
NRUDT was originally proposed by D. bernstein in 1996 to deal with the adverse effect of the Return-Receipt-To (RRT) header when used in mass mail and is merely a request for notification, unlike Delivery Status Notification SMTP extension. NRUDT doesn’t guarantee the email delivery, but provides just another way of trying to confirm the delivery of the message.

More information about NRUDT in the original proposal:

The UNIX sendmail program has for many years supported a Return-Receipt-To (RRT) header field that requests a notice of successful final delivery. Notice-Requested-Upon-Delivery-To (NRUDT) has the same basic function. The big difference is that RRT lists the sender’s address, while NRUDT lists the recipient’s address.

This change is critical. RRT works poorly for messages to multiple recipients, because it requests a notice from every recipient. RRT in a message to a large mailing list produces a giant, usually unintentional, flood of mail. This problem is so severe that RRT has been disabled in recent versions of sendmail. NRUDT is designed to be adopted immediately, with minimal disruption, as a solution to the problems of RRT.

Reference: http://www.sendmail.org/~ca/email/qmail/RFCNRUDT.html

3. Errors-To header injection
Errors-To header was an old hack to provide what is now passed as envelope sender address, and was used to route bounced mail to the list maintainer. It is not a standard and is deprecated, but some older versions of Sendmail still use it. As of v.8.8, Errors-To is supported only if UseErrorsTo option is set to true in the config file.

RN uses it to make sure that in case of a bounce their server receives a notification (alongside with the envelope sender) which can be then analysed by their software depending on the response.

4. X-Read-Notification header injection (if you select it to do so in the options of your RN user account).
It looks like this on the email:

X-Read-Notification: Courtesy of ReadNotify.com – hthhtp://www.glsebkhjbseoivr.ReadNotify.com

5. X-Confirm-Reading-To header injection (if you select it to do so in the options of your RN user account).
It looks like this on the email:

X-Confirm-Reading-To: sender@realmailaddress.org.jzfsasdqvclffc.emsvr.com

6. Content-Transfer-Encoding header injection

When received, the email seems to have been reencoded using Base64 encoding, which is used as a quick and insecure way to obscure secrets (passwords on confirmation emails, for example), as well as binary data (i.e. images). Spammers use Base64 encoding to bypass rudimentary anti-spam controls that cannot recognise keywords encoded in this way, as well as to encode image-based spam email.

RN uses Base64 to encode the whole body of the email, which might actually raise a red flag to the anti-spam solution on the receiving end, therefore affecting deliverability if the spam filter is set up to block Base64 encoded email for simple reasons that only ligitimate mailers have got nothing to hide.

Search for Base64 decoder online.

HTML injection

Apart from the above mentioned headers that attempt to track the email actions, RN also uses HTML code injection as follows.

1. DIV tag is used with an ALT attribute, which is not part of standard DIV attributes (TITLE is used instead)

In RN email, the whole RN injected HTML code is wrapped into the DIV tag like this one: <div alt=”fwe98hw243ui56jk.”></div>. The fwe98hw243ui56jk string is used afterwards in all the tracking features of the email.

2. Images are used with a moz-do-not-send attribute. The reason for doing that is to bypass a document composition flaw in mozilla-based clients that add inline images to the email as attachments:

When composing an HTML e-mail in Mozilla you have the option to
include inline images, either as an attachment or as a linked URL.
The problem is that when you finally get to send the email, mozilla
automatically attaches the image to the message, even if it was added
as an inlined URL – This resulting in a overblown email messages &
unneeded bandwidth waste.

The immediate solution to this is setting the IMG tag with
moz-do-not-send=”true”

Reference: http://mirror.hamakor.org.il/archives/linux-il/11-2004/12882.html

3. Table background images

This is just a simple table background image inserted into the <TD> tag.

4. Muted sound file (!)

RN also implements a request to a WAV file, embedded into the <BGSOUND> tag, presence of which means that the file should be downloaded and played automatically, therefore triggering the read receipt. The volume is muted though by using a VOLUME attribute set to “-10000″ and the source of https://tssls.fwe98hw243ui56jk.ReadNotify.com/nocache/fwe98hw243ui56jk/rspr47.wav (notice the presence of fwe98hw243ui56jk string, exactly as it appears in the point 1 above).

5. <TITLE> tag that is left open on purpose

RN’s HTML code uses a <TITLE> tag that isn’t closed and contains a very long string of several entities in HTML notation, which denote zero-width joiner, zero-width non-joiner, left to right
mark, and right to left mark.

The open <TITLE> tag causes those characters not to display, but just sit there – I am not sure what the reason for that is.

Upon digging further, it has appeared that Alexa gives more details on readnotify.com and the number of other web sites that have been spawned by the same company and even look the same:

Self-destructing-email.com, Readnotify.org, Readnotify.biz, Selfdestructing.com, Readconfirm.com, Readverify.com, Selfdestructingemail.com, Selfdestructingmessage.com

Quite a dodgy thing to do nowadays, isn’t it?  And what about brand positioning and reputation retention? Seems just like a cheap shot at trying to gain market share by multiplying without giving the quality a second thought.

That’s all I have managed to find out so far, so if anyone has more information or have spotted a mistake of mine, please email me.