That’s Not Your Email Address

I don’t think I have a particularly common name, but I’ve received email intended for at least _four_ other John Rubles. This creates awkward and amusing situations. Here are some of my stories and some lessons we can take from them for implementing email-based account systems.

## John #1 Gets Confused
In December of 2009, another Ruble family sent out their annual Christmas cards. Unfortunately, they miswrote John’s email address. His friends and family, excited to see that he had an email address, began sending me personal correspondence.

I came to learn that this wasn’t just a typo; rather, it was a case of what XKCD calls [reverse identity theft](https://xkcd.com/1279/): John (and/or his wife) believed that this was his email address, and the Christmas cards were just the first of many places they provided it.

Fortunately, almost all of the misdirected emails were sent by humans, so I’ve generally been able to reply and tell the sender about the mistake. Then they could contact their John via other means to determine his correct email address.

_Lesson: though humans make mistakes, they’re also pretty good at fixing them. If you’re implementing an email system with computers, you’re already at a disadvantage._

This John continues to occasionally enter an incorrect email when ordering something online. I don’t know how this happens, but I _do_ know a little about his preferences for dress shirts and mail-order steaks.

## John #2 Signs Up For A Dating Site
In 2014, another John signed up for a popular dating site. With my email address. A site that, at the time, was not sending account confirmation emails.

Immediately after receiving his welcome email, I received a receipt for the purchase of a six-month subscription, and then shortly afterwards I started getting notified of matches and messages and winks.

I was in a tough situation. I thought through a few options:

– _Set up a mail filter to delete the emails:_ This would stop me from having to see them, but it would be trouble for John later when he needed to receive an important account email, such as resetting a password. I was also uncomfortable with continued access to his dating site activity.
– _Reset the password, sign in, and cancel the account:_ This would also be bad for John, as I’m pretty sure his subscription wouldn’t be refunded.
– _Contact the company:_ I’m pessimistic enough that, initially, this didn’t even occur to me. I eventually tried, and received no response. Pessimism reinforced.

At the time, the site was also sending plain-text passwords. This is a bad security practice, but it offered a way out: I wound up messaging John within the dating site—from his own account—telling him to fix his email address. It worked.

_Lessons: Implement email confirmation. Offer a public contact mechanism and actually answer it._

## John #3 Does, Too
Last year, _yet another_ John signed up on the _same_ dating site, using my email address. This time there was no plaintext password, and there _was_ a confirmation email. Progress!

I never clicked the “confirm” button, obviously, but that made no difference: John kept using the site, and I kept receiving his emails.

Fortunately, this John hadn’t paid anything, so I reset the password and cancelled the account.

_Lesson: Email confirmation alone isn’t enough: You must gate important pieces of your website’s functionality behind it. E.g., users can’t send messages until they confirm their email address._

## John #4 Signs Up for Twitter
This year, somebody signed up for a Twitter account with my email address, and something about the confirmation email caught my eye:

Did you see it?

This was the first time that I, as the erroneous recipient of a signup email, had a clear action I could take to resolve the problem. I clicked the “Not my account” link, submitted a form, and the problem went away!

_Lesson: When building an account system, don’t solely consider the happy path. Enumerate where human errors may occur, and aim to offer resolution mechanisms for each of them._

## Closing Thoughts
These experiences have made me an advocate for deeper analysis of signup workflows. Here are a few things to consider when you’re building one:

– Security: What damage could a malicious email recipient do?
– It’s not always the intended recipient who makes the mistake. Consider whether accounts can get into your system via any mechanisms other than self-service signup (phone, paper, CSV import). Are other humans involved? How are errors handled in _those_ workflows?
– Thought experiment: Imagine if, instead of using a transactional email API, you implemented your communication with a team of empathetic humans. What kinds of exceptional cases could they handle that your robot cannot?
– You may be able to opt out of this whole headache by using a third-party identity provider.

If nothing else, hear my plea: Please, please, _please_ implement email confirmation, and remember that the feature faces _two_ distinct personas: _the right John_ and _the wrong John_.

Conversation
  • Thomas A says:

    This is the same problem I’ve had for years. Very annoying. Thanks for speaking out.

  • Tom says:

    This is the same problem I’ve had for years. Very annoying. Thanks for speaking out. Twitter has it right by the way. Like your work flow.

  • Tyler says:

    There’s a good suggestions webpage in the event your concern can be an simple and general one.

  • Cody Richard says:

    THIS IS TIME ERINE AND BERT

  • Comments are closed.