Vision and Concept

During the course of early development I realised there was a use-case I’d missed. Fairly simple use-case with a capability which has a limited effectiveness against spammers with good opsec.

I use paid-for tracking services for court document service, notice-before-actions, some subject access requests and when sending enquiry emails to spammers. This latter use-case is useful for finding footholds for intel packages on spammers trying to stay hidden. Depending on what desktop system they’re using or how sophisticated their webmail / mobile mail client is, I can get a verification the email was received – and even sometimes when it’s read. Very occasionally I’ll also get meta-data based on a document being opened.

But because I don’t send a lot of these emails my company is paying for a service which it doesn’t use too often, and are paying for data and web servers anyway.

Why not kill two birds with one stone and deliver our own document and email tracking service? During the design of this service we’re sure to learn something useful in our wider vision for Ringo Dingo, plus we can open-source it once it’s mostly engineered.

Payloads

When I send an email I want to know it’s delivered. If I don’t get a bounce-back with error I know it’s reached the recipient – whether they open and read it is their problem as delivery is complete.

Once it’s opened I want to see if I can trigger a request back to one of our servers – via domain aliases if needs be – to call a web service. This service would gobble up whatever information was available to it, although I’m going to assume that the mail client may:

1. Allow script execution
2. Prevent script execution
3. Block external web requests

In the first scenario I’ll assume that a standard JavaScript call will be made within the email window. I can write some obfuscated JS which isn’t readily detectable by anti-virus which collates as much information via DOM as it can, and which then makes a RESTful call to our web service.

In the second scenario this won’t work, but perhaps I can use an IMG element or similar to download something from the web service. In this case I’ll get the web service to respond with a transparent 1×1 pixel gif, and use as much information as I can grab from the request and it’s headers.

In both these scenarios it may be useful to also duplicate each of these calls so that if they are available within the mail client, a domain-based calls is made as well as an IP-based service call. This would highlight whether our domain has been added to any ad-blocking DNS filters. As we’re not using this to spam people or for any nefarious purposes I’m ok with this being an edge-case.

The third scenario is much more problematic. Here we’re not going to be able to get any direct tracking information without either doing something naughty or having the subject actively interact with something in the email. When we look at sending documents I think using links to these documents is the way forward here, as we can secure documents in a stored area on a server and ensure only recipients with the email links can access them.

Data

The information sits in three categories here:

• Information about the recipients systems
• Documents we want to make available to the recipients
• Authentication tokens allocated on a per-recipient-document combination

In both cases we need to ensure that meta-data stored in a database is stored on an encrypted volume – will need to look into MSSQL-style database encryption on PostresSQL too.

In order to generate a new authentication token for a document, I’ll need to ensure that that request itself is authenticated and authorised. Because this is likely to be via a web service I want to protect the transport of that request; protect the username-password in the payload of the request; and ensure that the verification keys on the database server are hashed and stored on encrypted medium.

I’ll also need to ensure that the access to this security silo is segregated from the rest of the meta-data in case there is a breach; and only accessible by the API via stored proc.

Design and Engineering

Ok, so we have our vision and principals defined, let’s get busy. Gitlab repo created but we can use this piece of work to check & test some principals for engineering we’re going to re-use in Ringo Dingo overall.

I want to take the ideas I’ve considered in CI previously and apply them here. Lessons learned will be invaluable in the other repositories that will make up the Ringo Dingo platform.

The first work to be done is documenting the design – I’d already added a lot of this but I think I’m now going to rework this from README.md into Wiki proper.

Repo: https://gitlab.com/Ringo-Dingo/rd-tracking-pixel (may still be private until first release is out of testing)