Pardon me if I jump in here and change the direction of this discussion to something more relevant.
What the IETF should do: Amend RFC 2822 to change the definition of an email address in a way that is entirely backward compatible, yet supports aliases. I propose a change like the following: (pardon the ambiguity)
addr-spec = local-part [ "+" password ] "@" domain
local-part = dot-atom / quoted-string / obs-local-part
password = atom
domain = dot-atom / domain-literal / obs-domain
domain-literal = [CFWS] "[" *([FWS] dcontent) [FWS] "]" [CFWS]
dcontent = dtext / quoted-pair
dtext = NO-WS-CTL / ; Non white space controls
%d33-90 / ; The rest of the US-ASCII
%d94-126 ; characters not including "[",
; "]", or "\"First of all, realize that there are already implementations deployed that recognize email aliases -- "plus aliases" in particular.
Second, there are implementations that recognize aliases, but in incompatible ways. (Sendmail and Exim recognize a "+" sign. Qmail recognizes a '-' sign. There are still others.) Therefore, it is incumbent on the IETF to update the standard for an email address so that implementations can interoperate. There are also new products that depend on a plus-alias-like mechanism to create useful filters. Without standarization, there is the real possibility of products that don't interoperate.
Third, this definition is entirely backward compatible, so it has absolutely no impact on existing (correct) implementations.
Fourth, with a standard for aliases, new products can be created, and perhaps used in creative ways to block spam. Without a standard, new products will be created, but they will not interoperate. I could envision mainstream products being modified to support plus aliases in a way that makes it easy for unsophisticated users to use them. But that won't happen if there is no chance for interoperability.
Fifth, plus aliases have an impact on the S/MIME standard. I would like to get one personal ID certificate and use it with many aliases. That won't happen if aliases are not recognized by a change in the standard. Software that checks the identity of the sender SHOULD remove the extra "password" part when comparing the sender address to the email address in the certificate. That would provide the same assurance of the sender's authenticity, while allowing the sender to create a family of related aliases. The way to think about this is, the local-part and the domain establish identity, while the "password" is used only in delivery. If you think S/MIME is already difficult to use, imagine needing a different certificate for each alias you use.
How this impacts spam:
I have talked to many individuals about the use of "plus aliases." Most responses I get fall into two categories: (1) some have never been aware of plus aliases, and (2) some are aware of them but think they are too complicated for average users. On the last point, I am not sure I agree entirely. Yes, they are too complicated as things are now. But good software designers are able to make complicated things simple. (There are already software products that try to make the use of aliases entirely transparent.)
I think we could explain to unsophisticated users that the extra part in their email address, if they choose to use it, is a "password" that keeps junk out of their inbox. They will understand that. We can also explain to them that if their email account is overrun with spam, they don't have to change ISPs to get a new email address. They can just change their password. And, I think that the popular email client applications could be changed to make it very easy to use different aliases. I'm not a user interface expert, but I don't see why something as simple as password-protecting a folder in your inbox should be complicated. One thing I do know, is that there are many unsophisticated users who feel almost helpless against the onslaught of spam. Some are driven to change ISPs. I think many would welcome the opportunity to password-protect a folder in their inbox, and give out the "password" to only close relatives and friends.
Using plus aliases is purely optional. Users who want things simple continue life as before -- not using plus aliases. Users who choose to receive a limited amount of email on their cell phone or PDA can use an alias that they give out to only a handful of people.
The IETF is an organization that creates standards. I believe we need a standard for email aliases -- using a plus sign or whatever. With almost no impact on existing infrastructure, we can give creative anti-spam engineers a new tool to use, and I am eager to see how such a tool might be used. But regardless of what one might think of the potential to control spam through the use of aliases, creating a standard for aliases is work the IETF should take on.
-- Doug Sauder Hunny Software, Inc