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