1) A native message tagging system
user+tagname@host.com can be filtered via rules on the client side into different folders, etc. I don't care so much about this personally, as I tend to have very few folders and generally adhere to the "
Inbox Zero" approach to email management.
However, I do use (and recommend)
Evernote, where tagging is an important organizational tool. One can create notes by sending mail to an Evernote email address, and the company recently
announced support for tagging notes sent via email by using #hash #tags in the subject line.
This support is nice and I use it frequently, but a more elegant approach might have been to support the same functionality via +tags in the Evernote address. This would leave the subject line uncluttered, which is important in cases where Evernote is not the only recipient. For example, it's a bit strange to send an email like the following:
Re: Your mail #tag1 #tag2
but the alternative would be natural and transparent to all involved:
I tried sending mail to my Evernote account with +tags in the address just to see what would happen, and they failed even to route it to my account. I received the following bounce notification:
Evernote was unable to submit your note for the following reason:
Emailed note was received, but Evernote did not understand the email address. It may be mis-typed, or the user may not exist. Please check to make sure the address was properly entered.
Too bad, but there's nothing conceptually stopping them from adding this functionality tomorrow (or at least letting the message through!). Sending messages to different Evernote notebooks could even be supported with hash tags in the address (per RFC 3598, sub-addressing is not limited to the plus character). For example, an email to
me.4el72#london+meal+expenses@evernote.com would create a new note in the notebook named 'london' having tags 'meal' and 'expenses'.
2) Lightweight disposable email addresses
Disposable email services like
Mailinator have existed for ages, but one could use sub-addressing to achieve a similar result. Specify a +qualified version of your email address when signing up for a service online, and then filter it at a later time if mail from that service is no longer wanted.
Pro: Zero creation overhead. The 'creation' of the disposable address is as simple as typing "+disposable" in addition to your usual
me@mail.com. Some services make it nearly this easy, in that you can send an email to
whatever42@disposablemailservice.com, and then go check the account, but it still requires knowing about the service and then checking the 'inbox' via that service's website, negotiating their UI, and so on.
Con: Those with malicious intent can easily subvert the scheme by truncating the + and everything that follows it. Your actual email address is in no way hidden.
Con: You have to manually add a filter to 'dispose of' the email address. Kind of ruins the productivity gains realized by zero creation overhead as above. This can be mitigated somewhat by always using the same +disposable tag, and just routing it to a 'disposable' folder in your email client.
You might say this approach is convenient but insecure. If you wish to truly hide, it's not the way to go; it may be ideal if you basically trust the service in question but want to hedge your bets against potentially unwanted email in the future.
3) Spam tracing
A slight variation on the above. Supply a different +qualifier each time one's email address is provided to a merchant or service online. If mail is received with that qualifier from anyone other than that original merchant or service, you know exactly who is selling your data. Unfortunately, as mentioned above, any smart spammer would know to shave off the + and everything after so as to hide the origin of the list. This is probably a common spamming 'best practice' already (there's a book title I'd love to see).
Caveats
* Apparently, not all mail servers implement sub-addressing functionality when receiving messages. GMail certainly does, and I would presume that most modern servers maintained beyond 2001 (the date of RFC 3598) would provide support.
* Certain mail servers will reject attempts to send messages that have a '+' or other seemingly (but not actually) non-standard characters. Hotmail for example, is notoriously restrictive.
* Often, web forms will be too restrictive in validating email addresses, and will not allow a form to be sent with a +qualified address. I actually ran into this the same day I found out about sub-addressing.