

How Close.io (YC W11) built per-recipient email tracking - anemitz
http://hack.close.io/posts/building_better_email_integrations_pt_1

======
huhtenberg
> _we can send unique message content to each recipient of an email while
> still having recipients believe they are receiving the same message_

So you _know_ that people don't like receiving personalized messages that are
tracked and yet you are proud that you have devised a way to shovel them down
their throats anyways. Good stuff.

(edit) I would've not minded if this were purely technical post on how you set
things up, but the way its edited at the moment just reeks of disrespect
towards those on a receiving end of your emails.

~~~
disbelief
The emails would be personalized and tracked regardless, all that this does is
improve the tracking by identifying which recipient opened the message instead
of a more general "email was opened" tracking event. It's not exactly
trickery, just creative use of SMTP commands. Also, it still relies on a
tracking pixel, which as usual won't work if the recipient has images disabled
in their email client.

~~~
mike-cardwell
"which recipient opened the message" and: The times they opened it, where they
were when they opened it, and what operating system and user agents they were
using when they opened it.

~~~
philfreo
All of those things are possible with any simple tracking pixel anyway. The
only difference here is being able to distinguish specific recipients from a
multi-recipient email.

~~~
mike-cardwell
If you visit a website and that website gleans this information about you,
that is one thing.

If you simply receive an email and read it, and the sender can glean the same
information, that is something entirely different.

~~~
philfreo
Tracking pixels in _emails_ have been around for many years and are used by
almost everybody. That's why many email clients block images by default.

~~~
mike-cardwell
That is not an argument for doing it. As I wrote sarcastically in the other
thread on this page:

    
    
      "Oh, but everyone does it, so it's ok right?"

------
jensenbox
This is really in poor taste. Can you imagine if the email to Bob said "hey
lets meet at the pub at 6" and the email to Alice said "hey lets meet at the
pub at 4".

I know this is unlikely, but sending an email that looks like each party is
getting the same thing but in fact are getting different emails just is bad.

The tracking thing is not a big deal, seems like everyone does it. Just block
images and you are golden.

~~~
anemitz
Author here.

You're entirely correct that this part of the SMTP spec does potentially allow
for dubious behavior -- and that's one of the reasons I wanted to publish this
article. I have a feeling this is one of the little-known secrets of email
sending which we should all be aware of.

EDIT: Also, I'd like to point one that the real textual content of a message
can't differ when sending through Close.io so the scenario you explained above
isn't possible within our app.

------
veidr
Ignoring the terminology errors, and the fact that this is a pretty scummy and
uninteresting business model (it's kind of like blogging about the awesome
architecture you built to predict when people will be at home eating dinner so
you can robocall them with telemarketing crap right then), this kind of system
is also inherently unreliable.

None of my email clients, on OS X, Windows, or Linux, will show that pixel
unless I press a button or take some action.

And I believe that is increasingly the default behavior of email clients,
isn't it? Which means this technique will increasingly not work, and there is
nothing close.io can do about it.

~~~
anemitz
The internet is fun, so I'll bite.

> _scummy and uninteresting business model_

We make a sales communicate platform that integrates CRM + calling + email.
<sarcasm> You're right, it is a pretty uninteresting business model in that we
don't use some new-fangled financial instruments to cook our books -- it's
just boring ole' monthly recurring revenue at a SaaS company. </sarcasm>

Scummy? Don't even know where to begin on that one -- but if you're in the Bay
Area ping me. I'd be happy to sit down and entertain any ideas you may have
that we run a scummy outfit. Seriously. I really would like to understand the
context behind that statement. It's not something I take lightly as a founder.

> _None of my email clients, on OS X, Windows, or Linux, will show that pixel
> unless I press a button or take some action._

Yes and no. You can set most clients to load images by default -- I haven't
tested the default settings on all clients so I can't speak about what
percentage that accounts for. I'd assume someone like
Mailchimp/Marketo/Pardot/etc. may have published some interesting findings
about this.

You're entirely right, however -- we can't do anything if a client blocks
images. And that's OK. Tracking is a feature our customers love being able to
utilize when they can, but they also understand that it's not entirely
accurate.

~~~
veidr
By "scummy" I am talking about the same thing as the other people in this
thread talking about "poor taste", "ethics", and "morality".

Surreptitiously tracking users without their knowledge or consent (and I mean
the _end users_ , not _your_ users who are paying you to do it) just isn't
something cool to brag about, any more than robocalling people at dinner, or a
thousand other things that are nevertheless legal and make monthly recurring
revenue for those who do them.

Not saying you shouldn't be able to do it; a lot of unseemly and faintly
repulsive things happen in the name of marketing. I'm just saying it's kind of
a lame thing to do in general, and it is pretty off-putting to read a blog
post that basically says, "Look how rad we are for tricking all these people
and tracking them without their knowledge!"

------
mike-cardwell
"How Close.io (YC W11) exploited a technical loop hole in the way email and
the web works in order to mine data about users without their knowledge or
permission"

Oh, but everyone does it, so it's ok right?

~~~
disbelief
I don't get the "without their knowledge or permission" part. That could go
for anyone who puts a tracking pixel into an email. It doesn't apply
specifically to the "technical loophole" discussed in this article. I'm not a
fan of tracking pixels either, but this isn't really the point of the article.

~~~
mike-cardwell
Yes, that can and does go for anyone who puts a tracking pixel into an email.

And to address the: 'I don't get the "without their knowledge or permission"
part.' \- What don't you get about this? The recipient doesn't realise the
tracking is taking place, and the sender never asked permission to perform the
tracking, nor to store the data...

~~~
disbelief
I'm saying that the question of (lack of) permission is a different topic from
the specific SMTP technique described in the article. The SMTP technique
doesn't change anything with respect to privacy compared to standard tracking
pixels. The assumption going into the article was that tracking pixels are
already being used.

> the sender never asked permission to perform the tracking, nor to store the
> data

Well, in this case the sender would be someone using Close.io as their CRM. So
they actually almost certainly do want this tracking to be performed.

~~~
mike-cardwell
The authors use of SMTP and IMAP is confusing. This is a standard tracking
pixel, performed in the same way that everybody else does it. There is nothing
new here.

SMTP and IMAP are transport protocols. For transporting text around:

"By utilizing SMTPs RCPT TO command" \- He's not utilising anything special.
This is exactly how every other email that employs tracking pixels is sent. A
separate recipient and message body for each recipient.

"Remove any messages stored by the SMTP server" ... "Google's SMTP servers
store a copy of every message"

Nope. SMTP is used for mail servers to pass email about. An SMTP server
doesn't store mail, apart from in it's temporary queue before forwarding it
on.

"Store sent mail in IMAP" ... "If using a service like Gmail which stores all
sent messages automatically in IMAP" \- Again, you don't store email in a
message transfer protocol.

This article reads particularly badly because of the repeated incorrect use of
terminology.

[edit] And to address your comment, "they actually almost certainly do want
this tracking to be performed" \- "want" is an interesting word to use there.
If there was a tick box in the top right corner of peoples email clients which
said:

    
    
      Allow senders to track when you open a message,
      where you were when you opened it, and various
      pieces of information about your system
    

99% of people would untick that box.

~~~
disbelief
When you send an email with Gmail's SMTP servers, Gmail automatically stores a
copy of that message in your "sent" IMAP folder. This is what the author was
talking about.

~~~
mike-cardwell
Not "in your sent IMAP folder" ... "in your sent folder, which can be accessed
via IMAP"

------
geal
So, if I understand correctly, I can test if someone received a specific email
just by testing the tracking link with known email addresses? Fun!

