Default Honeypot

Email addresses are widely used, and sometimes necessary for critical services. But because they're so useful, they are also routinely abused. Bayesian spam filters help a lot, but don't protect from unsolicitied email in general.

But maybe we've been using email backwards!

Typically, we give our email address to another person or entity because we want them to contact us. What we don't want is for them to share our address with scammers or for their contacts database to ever leak. But breaches do happen, and they do share our email address with sketchy 3rd parties.

Instead of giving out the real address, give out a specific address unique to that recipient. So when I sign up for a Target account, I give them [email protected]. Likewise, when I sign up for e-banking, I give [email protected].

If I'm consistent with this convention, then I can reliably know that any emails addressed to [email protected] are suspicious. Or, at least I did not give my contact info to this entity on purpose.

This "just works" when giving out an email address. On the other hand, when I send email to others, they will still see my default email address in the "From:" header. To be consistent, I should change the From: header when sending mail to a recipient who expects one of my alises.

For example, if my bank thinks my email is [email protected], but I reply from [email protected], they don't match! So when I send an email to my bank, I need to make sure it specifies From:[email protected].

I can add a +comment alias in Gmail using these instructions, but I need to manually select that as my "From" address each time I send an email.

What if spammers figure out this trick? They can start sending spam to [email protected] and bypass my client-side filtering. This is true, but in these examples I've been using "friendly" aliases. Instead of using +bank, I could use a long random alias like +NVEWanfewVhilmzZqqQjjQJ382nefjfJ.

An email client could treat this convention as a first-class citizen, and recognize +comment aliases in received mail. If I choose to reply, the client could automatically choose the [email protected] as the FROM address in my response.

Even better, the email client can automatically generate nonsense aliases like username+NVEWanfewVhilmzZqqQjjQJ382nefjfJ on demand, ending the alias arms race with the spammer.

This concept also works for other services which give you a "default" contact point, but also permit creating new contacts. For example, Zoom gives you a personal meeting ID, but also allows you to create new meeting IDs. To apply this concept to Zoom, simply never use the personal meeting ID.