Skip to content

Spam: Plan B?

I’m interested in folks’ feedback on whether this is a good idea for dealing with spam. Or, rather validating legitimate e-mails such that they stand out better from the spam background noise (false positive mitigation).


  1. Sign up with, e.g. a vendor, and give the e-mail address as
  2. Use ‘plus expansion’ (with the dash instead of the plus to deal with the millions of lame web apps that can’t handle a +) to figure out who the mail is bound for. In this case it’s to ‘myusername’.
  3. Use the stuff on the right side of the delimiter and do a DKIM/SPF lookup. That is, verify that the mail came from who it says the From: is.
  4. If those all check out, score the mail way down. (less spammy)

If you could switch most of your contacts over to this method of addressing, it would do a good bit to ensure that mail was inbound legitimately.

There are a couple of potential drawbacks.

  1. it’s not very personable. This mostly is useful for automated systems where you get to tell it what the e-mail address is, it doesn’t help with me telling colleagues to send mail to bill@. The status quo is unchanged here.
  2. A spammer could just adopt this method for sending his spams. However, he’d have to set up a legitimate domain, and be sending mail with a valid From: to the correct To: from that domain. This totally kills the usefulness of botnets. Much of this value comes from DKIM/SPF themselves, but even a zombie sending mail through a legitimate gateway that’s attempting a stock spam, e.g., has no reason to cloak its identity and might pass an SPF/DKIM check. The odds of the zombie also knowing its own domain name and appending that to the To: field – well, that capability could evolve over time, but it’s hard to do and this is just an idea for a step forward in the arms race.

A few more options:

  1. Add a last part, a unique code, and check it against a pre-defined list. That is, if I sign up with, my address might be, and then I reject any mails To:*@ without the code. In that case, the domain name becomes redundant because I’m going to lookup ‘snoodles’ against ‘’ anyway, and if it’s not DKIM/SPF From:, the address was stolen and I’m going to reject it. But this means I need to maintain a list somewhere, with undefined software to manipulate that list, and, well, ugh, that’s an extra manual step.
  2. Some people (me included) like to do sorting on To: beyond the domain name, so there should probably be an extension syntax, perhaps would be something I could use. would also be valid.

I’ve been thinking about this since the unique e-mail addresses I gave to a couple vendors have been stolen but the spam I received to the addresses didn’t come from their domains (from a foreign address, no less). With this kind of system they would have been automatically rejected.

So, if you have thoughts on this, please leave a comment. Thanks.