Comments on using e-mail address as username for online services

I have encountered more and more online facilities using e-mail address as the user name. In my mind, this is a lazy way for the service to check or to provide a unique user name when creating an account. In some rare usage, this may be fine but generally this is a very restrictive form and the reasons are given below.

Using e-mail address has the following problems:
1) While it is unique in the universe of the Internet it does not uniquely identify a user of the service, thus unsuitable as a user name unless the service has other facility to deal with one e-mail address for multiple users.

For example if one manages several properties or funds belonging to different entities under some management agreement, it is often convenient to use one e-mail address for all these properties or funds. It is also possible that the e-mail owner owns all those properties or funds, it is unreasonable to base that identifier on an e-mail address which does not map to a unique entity; e-mail address is for correspondence - like a house address.

Who would then use a house address to identify a person living there when it can house several persons?


I have seen one service that uses the user name (aka e-mail address) as a proxy to a fund account. This then assume the owner of that e-mail address cannot have more than one funds - one may be for him and another for some other ownership arrangement with correspondence being sent to the same address. Clearly the developers have not model the usage requirement well.

This silly design is like the above house number analogy requiring a house to house just one person.

The assumption that an e-mail address uniquely maps to a particular person or entity is unsound. Don't do it. It is far better and more secure if your system generates a unique number, a la, account number, for the user.

2) The use of e-mail address as a user name can confuse user in that he/she has to supply to the online service the same password for e-mail account. This can lead to an increase (or subliminally encouraging) reuse of password, a dangerous practice.

To a less technically savvy person, he/she may be misled into believing that the e-mail provider now have access or linked to whatever materials available in the online service.

3) While it is infrequent, though not impossible or improbable, for people to change e-mail address, services that uses e-mail address for correspondence as well as for user identification inevitably prevent user from changing e-mail address. This is because it is using a very poor design pattern - one piece of data to serve two distinctly different and diverse purposes. The user name is to identify a user which an e-mail address does not and the e-mail address is for correspondence, like a house address which can be used by anyone living there to receive correspondence.

If you ask correspondence sender to simply put the address on the envelope no one in the household will know to whom is that letter addressed; you need to put the addressee's name (the user name). A person could one day moves out of that address; he/she retains the same name (user name) but simply changing the delivery address (changing the e-mail address). This happening may not be frequent but not improbable or impossible.

No right minded person would combine the two (addressee's name and the delivery address) but why do that in the computer system?

To address this kind of short coming, they then have to provide a means for the user to define an e-mail address for correspondence. In this situation which one should the system uses during account set up and validation purpose?

How to overcome this poor design as a user?

If you, as a user, are confronted with this problem - how to use one e-mail address for more than one users of the service - you may try this solution provided that:

• Your e-mail provider supports e-mail alias. GMail and Hotmail support them. If you provider does not supports this, set up a GMail account as a mail redirector.
• Your online service's user name (aka e-mail address) validation knows about RFC 822 - Section 6 Address specification. Those failing to parse this properly would reject your e-mail address with alias.

Then use e-mail alias (like Somebody+Property1@GMail.com or Somebody+Property1@Hotmail.com) to allow one e-mail address to be used for several entities. The '+' character in the local part of the e-mail address is valid and permitted under the RFC. If their developers tell you that it is an incorrect address, point them to the RFC.

Those thinking of using e-mail address as a user name to relieve them the task to validate its uniqueness needs to validate the e-mail address to conform to the RFC.

To me, the task of validating and ensuring a user name is unique within the system is far easier than validating the e-mail address because the latter needs to check:

• conformance to RFC
• that the e-mail provider supports the e-mail alias that the user enters, as the service has to make sure it is a reachable address to receive correspondence. If that alias syntax is not supported by the mail provider, conforming to RFC does not guarantee it can be used for correspondence.  

Here lies the danger of tying the two purposes to one piece of data, that is using an inappropriate design pattern.