Slashdot Mirror
Ask Slashdot: Name Conflicts In Automatically Generated Email Addresses?
New submitter matteocorti writes "I work at medium-sized university and we are considering reducing the number of domains used for email addresses (now around 350): the goal is to have all the 30K personal addresses in a single domain. This will increase the clashes for the local part of the address for people with the same first and last name (1.6%). We are considering several options: one of them is to use 'username@domain.tld' and the other is to use 'first.last@domain.tld.' The first case will avoid any conflict in the addresses (usernames are unique) but the second is fancier. Which approach does your organization use? How are name conflicts (homonyms) solved? Manually or automatically (e.g., by adding a number)?"
when i attended, Wright State used something like firstname.lastname@domain.tld, and for duplicates would use firstname.lastname.increment@domain.tldr
not necessarily the best... but at least it was low collission rate
http://www.kalzumeus.com/2010/06/17/falsehoods-programmers-believe-about-names/
How can I believe you when you tell me what I don't want to hear?
Why the hell does everyone assume western names?
Just do fullname@domain.tld. I really is that easy. In case of conflict you can simply add middle name or initial. It also fits names that are outside the typical western naming convention.
I work for a fairly large university (60K+ students), and using username@domain.tld has worked for us just fine... not that it's stopped almost every college and department from running their own mail servers.
We've had two username collisions at our company, we avoided them by adding a middle initial.
I went to eat some animal crackers and the box said, "Do not eat if seal is broken." I opened the box and sure enough..
Add a middle initial, or add an incrementing number. What is this, Easy Programming Questions Day?
Why not both? Port the existing accounts as username@domain.tld, but set up new accounts in your preferred format of first.last.
Have you considered possible privacy issues with using given names as email?
I'd recommend cage matches to the death.
Problem solved.
My university includes a middle initial to reduce duplicate names. When there is no middle initial, or it does not solve the uniqueness problem it will start enumerating the user names, for example john2doe@domain.tld
first.mi.last@.domain.tld; if no middle initial, use x. if still not unique, add letters to middle initial (ie. Stephen could be first.st.last)
-SaNo
Not sure why you would treat these conflicts any different than what you do already.
Its not like you have 30k users an no conflicts. Hell, I've got a company I do some sidework for that has 6 years and 3 are conflicting.
Why are you looking to change what you already have an introduce a new set of problems to learn.
You have to have a system, logically defined, this takes out the problem with people 'not liking' what they get.
Don't migrate existing users, leave them. Change it for incoming users. Its not like its hard to host subdomains. Assuming you have a clue, this is just a simple matter of pulling the info out of LDAP and putting it into a format your mail servers like, which I would presume you already have.
You seriously don't have more important things to do than try to consolidate email domains? Did you consider why multiple domains were used originally? Whats changed?
--BitZtream
Perhaps when sending an email the user does not want to reveal his or her real name. By putting names in email addresses you make this impossible.
Use usernames, allow full names optionally on a first come, first serve basis.
The name "john.doe@domain.tld" is not available.
Suggested alternatives:
"john.doe123@domain.tld"
"john.doe314159@domain.tld"
"john.doeABC@domain.tld"
I can mend the break of day, heal a broken heart, and provide temporary relief to nymphomaniacs.
Organizational-wise, we go with first.last@company.tld. If two people have the same first and last, the default is to go with first.lastN, where N is the next number (so, bill.jones@ and bill.jones2@.) But, you can change the first name you go by using a nickname or alternate (which is generally encouraged to reduce confusion), so Thomas vs Tom vs Thom vs TD (First initial, middle initial).
At the university I attended, professors and staff got their first initial and last name (bjones), students got their first initial and their 6-digit student id number (j111111). I don't know how name conflicts were handled there, though I suspect first initial, middle initial, and last name would generally do it.
...and then they gave the clashes a random middle name initial. It seems mind-numbingly stupid to me. It's like making everybody live on the same street. Yes it might be nice from a pie-in-the-sky administration perspective, but think of the users. Many mails now get sent to the wrong person, and the suckers who got stuck with the random middle names have to explain what the weird initial in their email address is. Sure, use central administration, but there is no point in putting them all on the same domains. The institution or lab domains are kind of like street addresses in the real world.
the first person gets first.last@domain.com, the next person gets nickname.last@domain.com so like bob.anderson instead of robert.anderson or they can just add their middle initial so first.mi.last@domain.com or nickname.mi.last@domain.com
I have 3 solutions.
First is to misspell names. Science has proven that you can unjumble all but the first character.
john.doe@company.com
jhon.doe@company.com
jnho.doe@company.com
Second one is to increment the punctuation. This may be a bit confusing, but at least everyone has their correct name.
john.doe@company.com
john,doe@company.com
john_doe@company.com
john-doe@company.com
etc.
Third idea is to have them share. Why do they all need their own? Things will be addressed to the correct name. If don't want to share emails, just change your name.
In our organization, any time there is a collision in our usernames we have the affected users--hereafter referred to as "the combatants"--fight to the death. It's cleaner than adding middle initials or numbers to the combatant's--hereafter referred to as "the victor"--e-mail address.
If usernames won't give conflicts, then use them. And for the people that wants fancier emails, you can put aliases as firstname.lastname while there are no duplicates
I worked at a large Uni too for several years and we had a different approach... Every single user on Campus had an ID, attributed sequentially... wether they would be students or teachers. The ID was used hs the username. That sequence had different starting letters for each type of user (teacher, student, fellowship, employee, etc). Then each user had the ability to create their own alias for usability on a per availability basis. First come, first served... The choice of alias was ruled with a policy that told what were the accepted type of aliases.
My university takes the unique usernames approach ( abc123@mail.domain.tld ), but also creates aliases for everyone ( generally in the form first.last@domain.tld , but the user actually can choose whatever they want, if there's a collision). Seems to work well enough.
My old company used first initial, middle initial, and the first 5 letters of your last name. Collisions were handled with numbers, so there were some usernames that were tdharry19@company.tld. It's the same idea as passwords, maximize your entropy to avoid collisions.
A lot of places these days have added something, usernames and e-mail addresses not being identical. Makes it a tiny bit harder to get usernames for your network. So your username is tdharry19, but your e-mail address is Tom.Dick.Harry@company.tld .
sudo make me a sandwich
I presume the old format looked like:
emailname@subdomain.domain.com
Make the new ones:
emailname.subdomain@domain.com
This should prevent any name clashes and still move all the emails to one domain and even preserve the similar format the users already have. New users may not even need their own .subdomain after the email name, but you'll be adding them as you go forward and can check for clashes when they are added and maybe just add a .subdomain to them, or numbers to the end.
Things you think are in the Constitution, but are not.
You are planning to break 30,000 email addresses? If so you are insane and if not you are just making work and adding confusion. Anyway, use their existing email address as an identifier to log into a unified system available from a single domain. Have all other hosts involved forward to that system. And hand out new addresses on the unified host only. As for naming? Let them pick.
Back in the day we did a first-come-first-served for the full.names, when there was a conflict the user had a choice of (reasonable) options like adding middle initial or something better than a number. In a mass conversion you generally don't have the time ordering to give preference, and with 1.6% you've got a few names to resolve. But you can still generate an email to those users and let them qualify their names more fully and then resolve the conflicts in those answers.
Point is, getting the users involved as much as practical up front reduces support pain later...
dt
it would be great for SALES to have FirstdotLast but you might not want your IT or Security folks to have an easy to guess name.
If you insist in doing FirstdotLast then use FirstdotMidotlast format (and hope you don't get somebody with a long first and or last name)
Any person using FTFY or editing my postings agrees to a US$50.00 charge
Partition with sub domains, it simple and effective. If your domain is too large and causing lots of conflicts, split into sub domains. You end up with simple user.name@cs.domain.edu. user.name@arts.domain.edu user.name@engi.domain.edu, or if you have a student body included student@ad.domain.edu through student@tz.domain.edu. As a perk you can route http traffic on the subdomains to the relevant sub groups website landing page.
Based on my experience, I expect 99% of your students and a non-trivial percentage of your faculty will just forward their university email account to their personal Gmail account. They won't much care what their university address is (okay, faculty WILL still care and express their opinions, even though they won't be using it).
The staff will be the only group that actually uses your email offerings with any sort of consistency.
#DeleteChrome
usernames != email addresses
Email addresses are intended to be public, and an organization handing them out to their users typically don't want them to be anonymous. And by its nature, as soon as an address is used to send mail it loses its anonymity.
LegendMUD
Get the people with conflicting names to change their name. Problem solved.
Bogtha Bogtha Bogtha
Yes, because I love logging into the library computer with
Username: AF382E258D2-C32B392E-5439
Password Th1s !s N0t My P4ssw0rd Th1s M0nth $pr1l
There comes a point where simply assuming that the users accounts will be compromised at some point or another and doing your best to keep damage to a minimum is better.
1) Black list IPs with suspicious traffic patterns (Multiple failed logins, multiple account attempts in x minutes, etc)
2) Least privalege
Student Joe P. Bloggs enrolls in 2013 and receives Student Services ID 13123456, IT therefore gives him:
username jpb.23456@college.edu
You're not giving away the store by embedding the full ID number but 3 initials (could use X for those who don't have one) and 5 digits would probably have few collisions
As others have pointed out any assumption you make about names is probably wrong for somebody. Some simple examples, i am on the system as 'samuel' but i am known as 'sam'. I have colleagues who are know by their middle name or by their anglicised name.
It sounds like you already have globally unique usernames, so that would be a good starting point. You could then offer people an alias, suggesting fullname, first.last or first.initial.last, but allowing reasonable alternatives.
Also remember that people will have given there email in a hundred and one places that they may not be able to (or remember to) update. So make sure that the old addresses still forward to the new ones.
Since people often need to look you up later, permanent alumni address forwarding would be a nice touch.
For example, give people addresses like bill.smith@2005.example.edu.
The pseudo-machine (2005) would exist to keep unique addresses to each of those names.
If people have truly identical names, add '666' to the second one.
For example John M. Smith with student ID 10403 becomes jmsmith403@domain.tld.
Is it a security risk? Yes, but good luck trying to remember your email address when it asd[wlvlkasp23342!1-dkej@domain.tld. And there will be push back from your university administration as well as the user base with the more secure approach. So unless you're ready to fight to the death on that topic, let it go and go with an algorithm.
That is the stupidest thing I have ever heard. That is the point of a password, to have an unguessable field that assuming minimal security measures are kept is unbreakable.
If the username is not something like your name of a display name than you might as well not even have one. two passwords are no better than one good one.
Troll is not a replacement for I disagree.
You work at a university and you are sorting out the email system? Well, wave bye bye to your job soon, because one day the suits will say "Hey, lets move to Microsoft's Live.EDU" and then the problem is somebody else's. [Or Google mail for organisations, of course]. Either way, the suits will wonder why university IT are doing mundane things like setting up email addresses when that can be outsourced. Cheaper.
Use the username as the primary email address, and allow the users to grab aliases on a first come, first server basis.
This signature is far too complex to have been created by chance.
People like short email addresses. Do intials plus a random number.
mjs54@domain.tld
Keep in mind that as a university you are going to have a much larger turnover than a standard organisation, so their strategies may not be suitable for you. I would suggest that using any combination of First Name and Last Name will give you a pretty large amount of collisions, either with current users, or with past users. Collisions with past users may not seem like a huge problem until you get a ton of new users asking you why their accounts filled up with donkey porn spam on the first day. Of course you could do something like including their first year in the account, i.e. joe.bloggs.2013@uni.edu. But it's probably just easier to use the username (as long as that is unique of course)
That was the whole point I was making, and the OP asked if they should use usernames. I am responding as such.
I came, I conquered, I coredumped
Mordac, the preventer of information services has spoken ladies and gentlemen.
"Hey there, I'm Gary Wilson. I'd like to get more information about this petition you're circulating, but I'm running late to class... can you email me more info?"
"Sure, Gary. Thanks for your interest. What's your email address? Gary.Wilson@myuniversity.edu?"
"No, it's generated using a salted hashing algorithm, it's actually 8msMWlk09$1)_23@myuniversity.edu"
"uh...... yeah, why don't I just give you my card, you can contact me later."
One college I have gone to uses a separate domain for students from faculty and administration, @stu.college.edu versus college.edu. They use firstname.lastname, and then firstname.lastname#. They use Microsoft Exchange. Another college I attend now uses a unique ID created partly out of the firstname and a seemingly random 7-digit number, so John9999876@college.edu. This unique ID is also used to login to the student center to access registration, email, etc. It is different from the actual student ID number. As they use Google Mail, it may be generated by Google. My daughter's university also uses Google Mail, but she was allowed to create her own ID, firstinitialmiddleinitiallastname#.college.edu. In business, I like to use firstname.lastname@business.com or firstinitialmiddleinitiallastname@business.com, with dupes using full first name or full middle name or both; sometimes using nicknames or fullnames, like bob vs. robert. I try to respect the preferences of the user if possible. You could use any combination of these. You could use child domains based on named colleges within the university, such as wpcarey.asu.edu or engineering.stanford.edu. Or you could come up with an automatic random email ID generator or use mainframe login ID's, etc.
Nothing to see here but us trolls...move along...
This is the first question you should ask. Once upon a time I worked for a department that managed its own email, and hence had it's own domain. Someone had the bright idea of consolidating to just use the central email solution in the interest of saving time/money, in spite of the fact that managing mail took very little time and very little money. Transitioning everyone took a lot more time than managing the original process, shoehorned people into arbitrarily small mail quotas (hint: do not tell people who cost $100+/hour that they need to manage their email to fit in an amount of disk that you can buy for a dollar), made them less efficient and less happy as they had to switch from mail clients they knew well and were happy with to unfamiliar ones they didn't like.
In the end, we spent more time and money making everyone less happy and less efficient than if we'd just left it alone.
As far as simply avoiding clashes, consider that this is one of the benefits of there being a hierarchy in DNS. You can have bob.smith@finance.domain.com, bob.smith@engineering.domain.com, bob.smith@sales.domain.com, etc. Is there an actual requirement for everyone to be @domain.com, or is someone just empire building?
We use easy to remember, RFC compliant UUIDs.
Easy to generate and we haven't had any username collisions yet.
Email me for more details, I"m at mailto://ddd74e74-58e7-4077-ab87-0037feef6013@f3be36f9-be76-4042-9ec2-e7df5bb01479.com
... and don't even use names. Issue them a number or nonsense sequence of characters like most big companies do. Your collision % is probably based on current students, right? Remember the current student body changes by 25% every year. Name collision will grow over time until common names ten years from now need to have a nonsense sequence anyway..
Using usernames exposes your users account names to anyone they email. That's not a good practice. Security by obscurity, I know, but it can help.
givenName.surName@ generally works pretty well, and givenName.middleInitial.surName@ in the case of a conflict should help. If there is a conflict at givenName.middleInitial.surName@, you can add an index, eg., givenName.surName.00@ - just make sure you do something like specify what characters are ok (for example, not allowing accented characters or whitespace).
You might also want to have policies and procedures in place to handle special situations - for example someone has a significant privacy issue or has a name that isn't... well... polite :) when you string givenName.surName together.
No identical twins. Then use:
genomesequence@domain.tld
You could alternatively institute a no repeat (first.last) names admissions policy, unless of course if you're an Ivy League school.
Set your phasers on "funky"!
that are free. Letting them pick their own username is a good example.
Don't FaceBook people unless they want it. 1. If it becomes known that first.last@domain is the pattern, every spammer will use it. 2. You've cited another problem in the question--what to do about all the Joe Smiths. 3. Advise users against using their real name; but if you use usernames they still have the option of using their real names if that's what they prefer. If it's taken, tell them to add a number until the system takes it.
I work in schools. I often have to generate the systems to make usernames, passwords or email addresses and the like. Sometimes several dozens of times over in a variety of formats and allowable restraints (I do HATE software / services that can't just let me enter whatever the hell I like, how long I like, and with spaces if I like, and handle it like any other string - passwords, I accept, but anywhere else is just another way to waste my time going back and forth).
Every single clever system you think will avoid conflicts, won't. Every single automated system you think will make "easy to remember / guess" usernames, won't. Invariably, you will end up with having to make manual exceptions, which will also nicely screw up any fancy scripts you make to work on the basis of a naming system.
In schools, especially primaries, there is pressure to make short, simple usernames. First name only? Won't be long before you hit two "John"s. First name plus initial? Now you'll get John Smith and John Sergeant. I guarantee you.
Anything more complex and you have the inevitable result that one of the results will be unfortunate or even obscene. First four of surname, plus first two of first name? I GUARANTEE you that you will end up with a swear-word, or having to tell a user that their username is "different" to everyone else because otherwise it would end up with a swear-word (I have at least two members of staff at the moment who are literally a letter away from being very offensive, and I once had a child from a muslim family whose username came out to something like 'porcine', which I didn't think they'd like at all). And eventually you'll still find yourself making a smitjo2 or whatever.
Okay, so full-name on everything? Now you'll get someone like with a surname like "St Matthew-Daniels" who has the most horrendous email ever to type in correctly (and thus has to take the step of having an enforced rename to "Mr Daniels" or similar on everything from the classroom door to their email in order to make things sensible - imagine being a 7-year-old asked to go find Mr St Matthew-Daniels and not knowing who the hell that is because they all call him Mr Daniels).
No matter what system you choose, you'll get someone else with the same name. It's inevitable. If not now, then when one of the women gets married and takes her husband's name, or when X's older brother with the same surname and similar first name joins, or whatever. Just by random chance you'll get a collision that will mess up any fancy system. I have at least 20 Patel's in the school I work in at the moment, a handful of Smith's, and I used to get an awful lot of similar-spelled Vietnamese or Chinese names too.
So keep it simple. Use firstname.surname@company.tld and have done with it (if your company is tiny, you can get away with firstname@ for a while, but the rule above will apply just the same in the end).
It's easy to generate in Excel from a database for CSV import/export, it's easy to manage, you'll lessen the chance of collision as much as reasonably possible without getting stupid (e.g. middle name), and you'll have to deal with exceptions anyway - so just put out the lists in a simple format like that and then do whatever corrections you need to make later.
Punycode.
This is a retarded question with an obvious answer.
Use unique user names as the primary ID, and allocate "first.last" aliases based on first-come-first-served (with profs and other staff getting priority).
Trying to divide things up into first/last or force any other convention upon names is asking for trouble.
So when a payment gateway's API asks an application to do just that to the name of the cardholder, how should the application conform to the API?
We use a combination of Last Name, First initial, and Student ID number. Basically, it looks something like: DoeJ123456@college.edu. The Student ID ensures that there will be no conflicts.
Eliminating an identifiable first name prevents random creeps stalking the female employees. (Yes, it can be a problem, both internally and externally.)
Our company eliminated first names and went with first initial, middle initial, last name with no separator: John C. Doe becomes jcdoe@domain.com.
For duplicates, the longest-term employee is assigned jcdoe, the next is jcdoe1... etc. Over 10,000 employees and only 7 conflicts that I know of and 3 of them are rcsmith. One is R.C. senior, one is R.C. junior and one is an unrelated woman.
The online company directory uses this policy as well: J. C. Doe - Director of purchasing, J.C. Doe 1 - Legal aide.
Beta sux! Join the Slashcott! http://hardware.slashdot.org/comments.pl?sid=4760465&cid=46173047
I would suggest you use first initial and last name, such as jdoe@example.com. That should make everyone except Susan Lut and Brenda Itch happy.
You're giving away one-half of the user's login credentials. Second problem is first.lastname@blah.edu could still be subject to collision and eventually is giving away information about the user making phishing campaigns much more effective.
The best solution I've ever seen is a place I worked for which had around 1500 employees. They used the first name of the person and first letter of last name "Jims" or "bobb" and suffixed with a 3 digit number "jims112" "bobb113" (they never used the 0 as it would get confused with the letter O). This allowed for 999 collision variants, far more than they would ever have for 1500 employees. What's more is when people would get phishing email with a salution of "Jims112, please find the quote you asked for below : quote.xls" people would know right away it was a scam as they weren't using their first name. Outlook still displayed the name as "Smith, James" even though the underlying email address wasn't phonetic so it wasn't a big problem.
Join the Slashcott! Feb 10 thru Feb 17!
Both at the university I attended and another university that I currently work at use 'username@domain.tld' for the reason that usernames are always unique. There are too many name conflicts in a large group of people. Where I work now, we offer users to setup custom email aliases where they could choose 'firstname.lastname@domain.tld', but it is on a first come first serve basis.
Look, I just made you read my signature.
Think of your users!!!
An email address is something very personal, and often used on business cards, spellt out aloud on the phone. So it should be user friendly:
1. firstname.lastname is pretty standard (usernames, IDs are not)
2. easy to spell (u47x81127092 is not easy to spell).
3. the unique ID should not be too intrusive (John.Doe.323892983 doesn't look much like John.Doe anymore)
4. 666-John.Doe may look right to an admin, but weird to your family
firstname.lastname is pretty standard these days. Just append a simple increasing number until unique.
first one (98%) is lucky and gets no number:
john.doe
all others will get a number:
john.doe1
john.doe2
What they have done at my company makes sense:
Use firstname.lastname999@domain.tld where 999 is a 3 digits random number (retry in case of colision, also improper funny numbers are left over).
This apply even for non-coliding names, the first one to be registered will have the digits also.
Reading the posts above, I find that it is the best way to go.
My university has a pretty weird system. It's LastnameFirstinitial@domain.edu. If there's conflict they add an extra letter. So the first John Smith would be smithj@domain.edu. The next one would be smithjo@domain.edu. If it's a really common name, they just add arbitrary letters. I know someone named Pat Kelly and his email is kellyzl@domain.edu. Always seemed strange to me.
We use username@, but the username is generally FirstInitialLastName, unless it's already taken, in which case it's "what do you think you'll be able to remember?"
But we don't have 30k users.
Silly stuff.
A username is meant as a unique identifyer, not a secret hash.
What could be fancier that showing that you are truly elite!
First one to register their name is the "winner" (have some display of primal instincts like jousting with Shetland Ponies)
John.Doe@doesitmatter.com
Second, your name gets run through the 1337 speak generator (http://www.quizopolis.com/leet-speak-name.php)
J0hn.d0e.The_j0u$7er@doesitmatter.com
PS: I should really get an account one of these days and quit this all too convenient Anonymous Coward posting.
In a name outside Western Europe and the Americas, the "chars that are not valid" may outnumber the characters that are valid in an e-mail address and accepted by most MTAs and MUAs. In such a case, what "known way" is the best practice?
When considering setting up addresses like full.name@domain.tld, it's worth taking a moment to bear in mind that having an obvious email address increases the chances of a successful spearphishing attack.
A phishing attacker only needs to know a few email addresses from the organisation to work out the addressing scheme they're using. If everyone has an easily predictable address, it makes it much easier to target other employees in the organisation with a spearphishing attack.
The larger the organisation, the more vulnerable it is to this kind of thing. The addresses of your public-facing employees are effectively public domain; they're (deliberately) easy to discover, and thus likely to get spam and phishing attacks. They are hopefully sufficiently aware of the danger to avoid being suckered too often.
But your non-public-facing staff won't be as aware of the danger, and won't be expecting the attack. You need to protect them (and your organisation) by not making their email addresses easily predictable.
At the university I previously studied at, they went through pretty much the same process when they decided that individual departments would no longer be permitted to have their own email domains. They set up a system to allow people transferring to the University-wide domain to specify their own name, with the limitation that it had to include at least one character from your first and last names (along with various other requirements). So if your name was John Smith, you could choose whether you wanted JohnSmith@university.edu or JSmith@university.edu or even ohmit@university.edu. Obviously your choices became more limited if there were other John Smiths at the university, but at least in that case you got to decide how to resolve it for your self. Presumably there was a list of banned strings, I'm not sure. In any case, I liked this solution because it allowed the user to decide what format they wanted to use and ensured that people were, in most cases, quite happy with their email address (though I'm sure some people with common names may have had some difficulty). After all, this is a university setting and there is no really convincing reason to make everyone use precisely the same format - standardizing on one format doesn't really gain you anything.
Do not use usernames in email addresses ,,,, Security ... half the information they need.
I'd much rather the email system leaked my username (which is mostly harmless) than my real name (that can be useful for identity theft, stalkers, etc).
I don't think this is secret info by any means so what we go with is a 3 character ID followed by an incremental number (ex: ABC1) then if another person comes on board with the same initials it increases accordingly (ex: ABC2, ABC3, ABC4, and so on). The user can then have the option of changing their displayed email name if they wish, but the account does not change.
Of course a down side is it REALLY pisses off women when they get married or divorced. I have had bodily harm threatened over not changing a freshly divorced woman's account. If she can convince the CIO and he tells me, then it gets changed; otherwise it might as well be a barcode branded on your forehead.
Tell everyone to get a gmail account and be done with it.
*you* don't have to worry about spam.
*you* get to downsize IT.
And it costs you $0.
My institution uses userids, which are a string of letters followed by a string of numbers, and an alias to real.name. I always use the userid, because it's actually easier to spell, with fewer ambiguous characters than my real name.
Give me Classic Slashdot or give me death!
How did you end up managing email across 350 domains in the first place?
my particular institution uses this:
First.last.year-of-entry@my-institution.edu
e.g. John Doe starting his course in 2010 gets:
john.doe10@my-institution.edu
And if there are more of them they use additional numbers:
john.doe101@my-institution.edu ...
john.doe102@my-institution.edu
john.doe1010@my-institution.edu
You'd think Security 101 would have mentioned the perils of security through obscurity.
First off, last time I checked, BrownUniversity allows its students (at least, not sure about the staff) to select any available username; they map it to whatever default name was auto-assigned. I really wish corporations would catch on to that.
Second, if you really want a quick and dirty way to migrate away from username@department.company.com, why not set everyone up with username.department@company.com ?
https://app.box.com/WitthoftResume Code: https://github.com/cellocgw
You perhaps don't realize this, but a lot of people do not go by their first name.
Where I work, addresses were converted to firstname.m.lastname## and it has been a royal clusterfuck. There are hundreds of thousands of users, so there were even a ton of firstname.m.lastname conflicts (so they added numbers). It resulted in complete ambiguity with e-mails going to the wrong people all over the place and was made even worse by the assumption that their first name is always what people call themselves. Was Jim's address william.j.smith12 or william.j.smith13?
I think you'd be criminally liable to knowingly set up a new system that *automatically* creates ambiguity and confusion where there was none.
Cheers!
Sean
Why the hell does everyone assume western names?
Because Western conventions are sane and trying to accommodate the truly demented conventions of some cultures is a ridiculous and costly burden. Names in some places of the world are sentences; unreasonably long, ambiguously spelled nonsense that morph very easily when identity is inconvenient.
Names like that are only still perpetrated by parents and cultures that remain oblivious to the importance of writing. Out of necessity the West has managed to tame that stupidity to some degree.
Promulgating our wisdom through our institutional prerogatives is a good thing. If you want to participate in the world beyond your stone age theocracy, please make the effort to trim that silly handle down to something reasonable. Oh, and stop using pictographs; n^26 is more than sufficient.
Thanks so much.
For your sake, definitely use UserIDs (adding a number for dupes).
Here at my (large) university, they use both for email, where first.last@school.edu is an alias for userid@school.edu (the primary email).
Though few people use the userID@school.edu email, it does help that the school assigns user-friendly IDs based on their given names (if a custom one isn't selected). Ex. Patrick Peterson -> userID ppeterso. To deal with dupes, they do add numbers at the tail end as you suggested. If a Parker Peterson comes in later, they get a number on the tail end - ppeters1, ppeters8, etc. The same methodology could be used for first.last aliases by default (either with First.Last3@school.edu), and people can add a limited number of common aliases (i.e. First.M.Last@school.edu, etc.) if they want.
That makes either email address friendlier than obscureID938@school.edu. (In my experience, most people still choose First.Last@school.edu first over userid@school.edu. And (more importantly, IMO) many users don't even remember email addresses anymore, and rely upon autocomplete in Outlook/Exchange, etc.
I've been a believer that we need more than one SMTP address. The username version should be limited to username@domain.local however, since you don't want to expose your usernames to the planet through email addresses. Then also have a first.last@domain.tld for Internet usage. If there are conflicts on the latter, I've been a fan of asking the user what they want.
Email addresses are somewhat personal, even if they're work/university email addresses.
I didn't like my email address at work, so I asked to change it. Standards, be damned!
I work for the Ontario government. Several years ago, we consolidated several email systems (about 60,000 people) into one: ontario.ca. We use real names (first.last@ontario.ca). Numbers are added by default by Exchange if an address is taken (first.last2@ontario.ca), but we let people pick whatever they want if they don't like that: middle initial, even the city they work in if the middle initial isn't enough. It doesn't really matter what their email address is, as long as it's appropriate and has their name in it.
Web Design Tips
No, please DO make email addresses some predictable variant of a person's commonly-used name. I cannot tell you how many times I've been requested to add person x from client y onto mailing list z in an email that was forward from person a to person b to person c to the customer service rep at my company on to me with no mention of what that person's email address is. You might think, why doesn't this idiot AC just ask? You haven't dealt with people in HR, doctors, or real estate agents who are posturing and being abusive in an attempt to get a discount on their bill. Their end goal isn't that they want person x on mailing list z; it's to somehow show that you're being rude and uncooperative by not just doing it, and asking a question that only someone who's obviously "illiterate" would ask like "what's their email address" will only result in further abuse. Even an incorrect guess is good enough to satisfy these people.
Bosses get their chosen email names. Staff get what's left. But from a restricted character set, letters, numbers, period, underscore and dash.
Students get:
<random consonant><random consonant><incrementing unique number><random consonant>@your.domain
Then let them configure email forwarding if they want. Bonus points if you allow them to add a +<some alias> to the user part.
That should work fine even for people without names or without names that can be typed on normal keyboards.
It's not like most students are going to use the email address as their primary nowadays.
In other words, you're saying "Do not assume that white people should be allowed to have their own countries"...
Which is advocating genocide. Well done.
Give the administrative rights of this mail server to someone else. You obviously lack the imaginative ability to do anything practical. Seriously.
And to the editors. How the hell is this news? It's some email admin needing help "figuring out" what to call his users. Seriously?
I post AC because I don't want anyone to know that I actually responded to this crap.
They used addresses of the form "abc123@school.tld" where "abc" were the initials of the student and "123" was a number that incremented whenever there was a collision in the initials. If you have over a thousand collisions you just add another digit.
Little known fact: The equals sign is a legal email character. You designate email 'mailbox' names as name=role@your.domain.
This means that you can have peterfox=headOfNerdyThingsDept@your.domain. In actual fact you'd have peterfox@ ... and =headOfNerdyThingsDept@... This means you can email *roles* as well as individuals. Perhaps I have multiple roles so roll out peterfox=%chairmanOfNihilistsClub@...
The full spec for how to use this template is in a paper I wrote being the top item on http://vulpeculox.net/ob/index.htm
So for example you might have toAll=+boozyParties@... for a mailing list.
I'd say there's an added security risk once you make it people's usernames, as then it makes it easier to run a dictionary attack against the ones you have.
Call them all "Marklar". The individual will be clear by the context.
It must have been something you assimilated. . . .
Your remaining John Smith must be a real badass...
I checked the methodology of three universities I've been to and got the following:
username (default first_last)
firstInitial lastName Increment
firstInitial lastName ExpectedGraduationYear
I never said the email address has to be the same as the username, all I said was not to use the username as part of the email address.
This has nothing to do with security through obscurity. This has nothing to do with ridiculously long hashes as a username, that was a mere example, and an easily automated way of creating user accounts.
The whole purpose of my original statement was that the email address should be different from the username. The username should also not be easy to guess, as it is just an additional piece of information that an attacker can utilize. The reason that a hash is a good idea is that it prevents people from guessing at usernames based on patterns like first initial last name as the username, but the users first.lastname@domain.
People around here cannot read nor can they comprehend.
I came, I conquered, I coredumped
Pick any one of the two, and make an alias for the other. Then each user can use the one he likes best.
You could always use a modified form of the US Department of Defense Enterprise naming standard. It works for hundreds of thousands of people, and could probably work for millions.
DEE follows the DoD Enterprise USERNAME, Display Name, and Email Address Standard under the authority of DOD Directive 8320.03 This directive is followed within DEE and DMDC for the creation of the persona and non-person entity @mail.mil email addresses and display names.
Email address examples as follows:
Enterprise username general form - {first name} {.} {middle initial} {.} {last name} {sequence number} {.} {persona type code}
Example of user mail address – John.E.Smith26.civ@mail.mil
Corresponding display name - Smith, John E CIV DISA ESD (US)
Non Person Entity username general form - {DOD Component} {.} {DOD Sub-Component} {.} {NPE Location} {.} {NPE Type} {.} {NPE Descriptor} (example: “disa.meade.esd.list.daily-updates”)
Example of NPE address – disa.meade.esd.list.daily-updates@mail.mil
Corresponding display name – DISA Ft Meade ESD List Daily Updates
One place I worked at used lastnamefirstinitial@wherever.com - which worked great until a Russian bloke started.
Andrei Vagin.
Just come up with identifiers that are convenient for you. My daughter's university does this; students end up with email addresses that look something like 78jqt7@queensu.ca. It so happens that the jqt part is the student's initials, but that doesn't really matter.
Think of an email address like a phone number. Except in rare cases, there's no connection between your phone number and your name.
The way we work this out is if two employees have the same first / last name we put them in a cage in the server room for a fight to the death. Which ever user comes out alive claims the email address.
Where I last worked, there were over 110K employees and we had plenty of people sharing the same name. Here's how it went.
Default: first.last@xxx.gov
Same names: first.middleinitial.last@xxx.gov
Still the same: Senior employee got first.middleinitial.last@xxx.gov. Junior employee got first.x.last@xxx.gov.
Still the same? Increment the middle initial. The first person with the same name as someone else got an "x", the second person got a "y", the third got a "z", and I don't think we ever needed to exceed that. If necessary, we would have just continued through the alphabet, starting back at "a".
The biggest single problem we had with names and email addresses was employees who were legally empowered to use a different identity when dealing with the public. Anything that the public might see (their name or signature on a document, their email address, etc.) was a pseudonym, yet we had to use their legal names for internal purposes. Undercovers are a pain but I assume the OP won't be dealing with that. :-)
Create a web portal (LAMP is fine). Authenticate it against AD/LDAP. Allow users to choose an email address. First come, first served. Make useful suggestions based on their name/initials. Implement workflow and approval so that junior help desk staff can approve chosen email addresses based on policy set by you (to avoid cooldude@x.edu). Make sure old email addresses remain as aliases foreever as these may be published in academic papers etc. You can keep the portal so that people can update their info and create new aliases when their name changes (getting married/divorced etc). Sorted.
At my school they just defaulted everyone to @.edu. If you were on the payroll, you could get them to change it to anything that was available.
College was last0000@domain.com, (first 4 of last name, 4 digits)
Uni is full first name, first two of the last name, and 2 digits
(1) You should support username@TLD. Do that even if you also do other things, as this is a handy mechanism for apps running in your environment to contact users.
(2) You should also provision first.[middle.]last@TLD. Yes, I know that first/middle/last is not universal, but in the real world (i.e., Western country, Latin character set in the prevailing language) it's close enough. People from cultures where that doesn't work have already adapted and will give you a first/last anyways. Use them.
(3) You will obviously find collissions in the above. You can do first.last.suffix@TLD - people understand that and accept it. The question is what should the suffix be? Someone suggested avoiding serial numbers, and that's reasonable, since they leak information about how many people with the same first.last you have. Is that a big deal to leak? Probably not, but hey - why leak it if you don't have to. Another common approach is to assign a random letter pair as a suffix. first.last.gz@TLD or whatever. Easy and more memorable than a number, I think.
I've got a nice write-up about this sort of thing here:
http://hitachi-id.com/identity-manager/docs/managing-user-identifiers.html
Good luck!
Doesn't "username" just push the problem into a "how do we create unique user names" problem?
At the university where i work, we use "professional_name.family_name" and if there is a collision, then try "given_name.family_name" and then "professional_name.middle_initial.family_name" and finally "given_name.middle_initial.family_name". And if *all* of those conflict, then we use the first one but add a number to the end of it to make it unique, and generate an exception report so that someone will be made aware of it and can contact the user in question to work out some arrangement for a unique e-mail address that doesn't include a number. Unless they like the number, of course, in which case they could keep it. This system works fairly well; we only have a handful of people to contact each year.
As an example, suppose there is an individual named Jonathan P. Smith who usually goes by "Jon". In that case, we'd try addresses in this order: ...and so on until a unique address was found. Note that in the latter cases that have a number, Jon would be contacted by phone to work out an alternate address of his preference.
jon.smith
jonathan.smith
jon.p.smith
jonathan.p.smith
jon.smith2
jon.smith3
jon.smith4
----- "I'm still sane on three planets and two moons."
Name Conflicts In Automatically Generated Email Addresses?
I know this is a silly question but why not to actually ask the affected users???
30K*1.6% is 480 people. Generating automatically a bunch of e-mails, grouping the conflicting names onto CC lists shouldn't be much of a problem. Put the autogenerated names in the body and use some special prefix in subject line. Ask them to put the desired names into the first line of the response and set dead-line. On dead-line, check for remaining/new conflicts and probably repeat again. That would reduce conflicts to probably a dozen if not less. (Or an internal discussion board or Wiki can be used instead to let people to handle the conflict and in some convenient form provide the feedback to you.)
As personal experience goes... I work in company with 50+K employees and the autogenerated names suck. You pretty much never can tell who is who. And with the constant restructurings, one can't even rely on the name of department in the LDAP.
All hope abandon ye who enter here.
My alma mater had usernames of 8 characters that started with the university's initials (two letters.... this part seemed a pointless idea to me) and the first six letters of the person's last name. In case of conflicts, numbering begins in the right most character and eats up however many characters it needs to.
so in the case of "Big University"
bujackso@biguniversity.ca ... ...
evetually, you'll have
bujacks0
bujacks1
bujack29
bujac158
In the case of multiple Lee's (which is inevitable): ... ...
bulee (the first Lee whoever went to university there)
bulee0
bulee1
bulee10
bulee999
bule1000
Ugh.
I was personally annoyed because I have a fairly unique last name that is exactly six characters long, and my brother was older, so he got the first username of our surname. I had an ugly number zero as the last character. I am forever traumatized.
Especially in AD you have to assume that everybody knows all user names. Every account has the rights to enumerate and read all nonsecret properties of every other account, and in most environments (especially university ones) getting access to one account is trivial.
Adding a bit of security-through-obscurity to the usernames is akin of putting a bike lock on a bank safe.
All email accounts use an unique numerical identifier as the "real" name. Inbound mail is directed to the account via an alias. Outbound email is rewirtten using the Generics table. Name space collisions on the alias/re-writes are resolved by hand.
Going forward, code logic prevents the self help portion of the email system from allowing name collisions.
Necessity is the plea for every infringement of human freedom. It is the argument of tyrants; it is the creed of slaves.
The University of Michigan foresaw the need for something like this back in the 1980s - more to have a common/unique login identifier than for e-mail, but e-mail addresses fall out of that, and the scaling issues inherent in it for something that covers three distinct campuses in Ann Arbor, Dearborn, and Flint.
UMich's policies about this have evolved a bit over the years - from being wildly open to being somewhat more restricted now, but the core philosophy is to let everyone choose their own uniqname (so long as it isn't in use by faculty, staff, registered group, alumni, etc.), and do the name to login/uniqname mechanism through a LDAP query. Currently we have in excess of 280,000 such unique names. LDAP did originate at the University of Michigan, as did COSIGN (a single-signon mechanism for web services.)
This has also helped for having a common authentication mechanism - so that only one group is responsible for managing IDs and passwords, rather than individual units and departments all over campus (not that a unit or department couldn't - but then they have the burden of managing the IDs and passwords, and have to deal with conflicts with the shared infrastructure. Most choose to use the shared infrastructure.)
BTW: Cosign as a solution for a single authentication domain is much easier (i.e.: cheaper) to manage than Shibboleth, but doesn't provide all the extra information that Shibboleth does.
All usernames are surname.number, where the number is how many of that surname have attended the university. tressel.3@osu.edu meant that Jim Tressel was the 3rd Tressel to attend OSU.
This username stays with you even if you leave and return years later.
What, me worry?
Don't assume that it is acceptable to refer to a
person by that person's legal name. Some people
do not like their legal first names for whatever
reason. In particular, referring to a transgender
person by that person's birth name can be rather
offensive.
In short, use usernames, not real names.
I think it works best when you give the user a little bit of input into it, within some bounds. You might have 3 james.smith users, but one really is called Jim, one is Jimmy, one is James. Give the users themselves a bit of leeway for resolving it, they'll be able to give you a better answer than just something lame like james1.smith or js2304@foo.com. Stop being such a control freak.
It really depends on what the usernames are like, at my university the username is [initials][year started][three random letters], so for instance, john doe starting in 2012 would be jd12ges@uni.ac.uk, however, if your usernames are just a random sequence of letters or numbers this wouldn't be a very good solution.
Columbia University, my alma mater, does intials + four (possibly) random numbers @columbia.edu. Example: xxx2105@columbia.edu or xx2033@columbia.edu . Works fine and you'd be surprised how easy it is to remember the four numbers of people you e-mail a lot. You can just run the numbers consecutively too, i'd imagine.
Here is the policy I set up at a university back when the world was a bit simpler, but the system worked well.
Firstly, don't use names as the account, this will already remove a lot of headaches.
Secondly, every university has a student number which is the key for most of the documents connected to the student. In my day this was the students Social Security number but I magine it is something else today. Use this number as the id, as it is really the id of the student internally to the computer system of the school. Students usually know this number well by the end of the year as they fill out forms with it.
You must remember that even if you have no duplicates now, you need to think ahead for when students leave the school and possibly keep their account for awhile. Thus many time more possibilities of duplicates according to name, but if you go by ID there will never be a problem, as it must be unique to the schools record.
If someone wants a more 'descriptive name', put it in as an alias. You will get almost no duplicates, and if there are you can handle the, on a one to one basis. If you are smart you can also sell these aliases ....
I wouldn't recommend SS numbers nowadays due to privacy, but the principle is the same. The university where I work now uses the application number that is filled out automatically on every application accepted by the school, and allows you in the web-email interface to choose an alias if you want later. From what I see most students don't bother, they just forward their email to their gmail or yahoo account.
.
I'm not even afraid to share my name online: David Johnson. Good luck with that one, I've always worked for companies that used the first.last@domain.xxx and they've always had thirty other people named David Johnson. I've had a number in the teens placed after my name even when my middle initial was used, and I currently have an underscore instead of a "dot" for the same reason. (i.e. david_johnson instead of david.johnson)
Hash output for a username is a terrible idea. It might be good for sites where people never have to know or type their username, or for sites where 'ease of use' is not considered part of the 'security' equation, but otherwise it just means users will have to write something else down (and probably put it on a sticky note beside their computer).
Besides, your username is visible in plaintext at number of times throughout your session. Trying to intentionally obscure it is a whole new level of stupid.
In my organization, we do this:
john.x.doe@foo.example (first one)
john.x.doe1@foo.example (second one)
john.x.doe2@foo.example
john.x.doe3@foo.example
john.x.doe4@foo.example
When I was an undergrad at Berkeley in the late 90s & early 00s, I believe the students and professors together added up to around 40,000... Everybody chose their own username (profs almost always used their first initial & surname), but the subdomain changed: everyone from around my time got user@uclink4.berkeley.edu, there were a *few* professors on uclink3, and I believe I saw only one uclink2. The last time I looked at the student paper a year or two ago, all of the addresses appeared to be at uclink.berkeley, however.
In any event, that worked well for us (at least on the user's end)... Also, given undergrads were in a massive faceless bureaucracy for the first time and often felt like we were walking student ID numbers, I think most of us really appreciated being able to choose a username that conveyed something about ourselves. Students have to transition into the adult world of boring "first initial lastname" official addresses soon enough, after all...no need to rush if it doesn't bring huge tech benefits.
Now mostly at Usenet:comp.misc & SoylentNews.org (it's made of people!)
Security through obscurity works very well at preventing your users from getting at the information that they would need to show how insecure the network that you administer is.
It's not like the world needs all that many highly-educated John Smiths anyhow. Bonus: Automatic improvement to diversity scores.
Subscribers just got random-looking numeric identifiers (phone numbers). Worked great. Not that hard to remember the important ones and write down the rest. No bullshit about real names. I'd love it if other systems did that.
As GP mentions, [some family names use] archaic characters from some ideographic scripts which do not have Unicode mappings.
Family names have also been seen to change spelling and pronunciation slowly over the centuries, and one that uses a Han character without a code point can be respelled to use characters with code points.
most commonly I have seen the ! used to stand in for a tongue click
Click consonants could be transliterated to Basic Latin using the letters c, x, or q, which represent these clicks in Xhosa.
likewise the enya (https://en.wikipedia.org/wiki/%C3%91) has no English equivalent
True, and normalizing "ñ" (n with tilde) to "n" would end up changing feliz año nuevo from "happy new year" to "happy new anus". I'd recommend transliterating it as "nn", reflecting its Latin origin and consistent with the secondary use of tildes for nasal vowels in Portuguese, or "ny", reflecting an approximation of its modern pronunciation.
I admin the mail servers for a company with two domains for email. Almost all of the company is under the main domain as first.last@domain.tld and the few in the other domain is mostly for business reasons (marketing). Anyways, we haven't had this problem. There's one common last name that three unrelated employees have now and probably 12 employees total since I started but with different first names so yeah, no conflicts. This is all beside the point, the suggestion I would make to help keep things legible and minimize (but maybe not eliminate) the conflicts is to use a sub domain relative to the user, for example at a company we could use john.smith@sales.company.tld and john.smith@accounting.company.tld. I know most companies probably wouldn't like this but it's better then john.smith5@company.tld. I'm sure for a university it would be more aptly accepted then at a company. Haven't given any thought on how you would segregate the sub domains at a university but I leave that to you. Maybe offer choices like it could be set by their major or user selection of fun sub domain names to add such as @comp-sci.university.edu for majors and choice sub domains like sports.university.edu or poetry.university.edu or whatever. I'd say given them a choice for the sub domain via a web page would be efficient and just don't show the choices for sub domains already used by students with the same first/last name. I'm just brain storming here. It's an idea you could use, or not. Hope it helps.
I work for a very large University. What we do is a combination there of. We have the first.last@domain.edu, and username@domain.edu both as smtp entries for the in AD so email pointed at either will work. For the Smiths, Jones, Rodriguez's, Ngueyn's, Lee's, Li's, and Chang's, they get first.last2@domain.edu or first.m.last@domain.edu.
Just have a few multiple formats that are in use to avoid clashes
For staff (they need to be professional)
first.last@
first_initial.last@
first.last_initial@
initial.initial...last@
For example, English explorer John Joseph William Molesworth Oxley
John.Oxley
J.Oxley
John.O (would work better with more unique first names)
J.J.Oxley
J.J.W.Oxley
J.J.W.M.Oxley
You could even leave out some of the dots
JJ.Oxley etc
For students, just fragments of names and a number if necessary, without dots
johno1
joxley1
jjwmo
jjo1
joh1
doesn't really matter as much for students. I expect they'd have a personal email for professional stuff, and for stuff that requires verification of a uni address, or contact by lecturers etc it doesn't matter as much.
You could even just use their straight student number
s3403253 etc
In Scotland and in Korea there are many people with full first middle and surname the same. The Korean solution is to have firstname.lastname at domain ONLY for the first registered person with that name and thereafter each new name added has a unique number (usually issued sequentially) after the last name before the domain. The same system is used by UK banks in Scotland. Your main difficulty skipped over above is whether the family name is first (as USA/UK ango-saxon practice) or allow also family name first as is Chinese, Korean and some European places. Forcing family name last is possible if you register folk with family name last. Also the Romanised name for Chinese should follow either old system or new system of romanisation but not both. eion.macdonald235@ domain
Regards Eion MacDonald
We went with []@domain.tld
where
<cohort year> is the two-digit year of expected graduation (I won't be here in 100 years!)
<number> (starting with 2) is used only if disambiguation is needed (in only a few percent of the cases)