JRR

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: 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.

This post originally appeared on Atomic Spin and may contain input and edits from some of my colleagues.