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).
- Sign up with, e.g. a vendor, and give the e-mail address as email@example.com.
- 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’.
- 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.
- 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.
- 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.
- 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:
- Add a last part, a unique code, and check it against a pre-defined list. That is, if I sign up with example.com, my address might be bill-example.com-snoodles@, and then I reject any mails To: bill-example.com.*@ without the code. In that case, the domain name becomes redundant because I’m going to lookup ‘snoodles’ against ‘example.com’ anyway, and if it’s not DKIM/SPF From: example.com, 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.
- Some people (me included) like to do sorting on To: beyond the domain name, so there should probably be an extension syntax, perhaps bill-redhat.com%bugzilla@ would be something I could use. bill-redhat.com-snoodles%bugzilla 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.