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)?"
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..
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
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.
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.
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.
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.
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.
There is a problem with the middle initial, if you have a branch in a country where middle initials are not very common, or in this case, if the university has many students from countries where most people don't have a middle initial. For instance, in my family, most people don't have a second given name and thus no middle initial at all, and my father's name has two front initials before his given name.
But I've seen a kind of "artificial" middle initial, where the first John Smith gets the email address john.smith@organisation.tld, the second becomes john.a.smith@organisation.tld, the third one john.b.smith@organisation.tld etc.pp.
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.
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.
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
"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.
I actually think this is a pretty good solution. If you used a unique incremented number each time someone with the same initials joined then something like that would work fine. 3 digits would allow for 999 employees with the exact same initials and gives everyone a name of 5-6 chars (assuming you limit to three initials).
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.
I have and the conflict is solved by reverting back to first_name.last_name format with a number appended at the end for the second (and later) full name with same middle initial or for all names without a middle initial.
These comments are my own and do not necessarily reflect the views or opinions of my employer or colleagues...
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
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.
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.
Yep. I know a good deal of larger public agencies that share their domain across tens of thousands of employees that are going this route(employee ID or badge number for public safety). Student IDs are no longer social security numbers, so there is very little from a security perspective to worry about.
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.
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?
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).
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
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
And for the people that don;t want yet another part of their identity being sent across the internet for all to see?
How about people that don't WANT their middle initial transmitted to everyone they email with?
I would suggest something like this.
[Title.]First.[MI.]Last[Increment]@domain.tldr
Give all the Professors with eg. Dr.John.Smith and if there are more then one Dr.John.L.Smith and if there are multible Dr John L Smiths then you go to Dr.John.L.Smith1
This can fix a lot of political problems right there. Because the Professors email addresses and the students wouldn't get mixed up as often. As well the professors with the same name will have less of a chance of getting an increment number.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
Agreed, roughly. Each user, I'm guessing, will have a unique ID somewhere? Matriculation number or similar? So set everyone up with an address like 9442377@abc.ac.uk and then give them all an option to set up an alias with a real name on a first come first served basis - they can either use the ID based address or find their own preferred john.h.smith43@abc.ac.uk alias, doing most of the work for you, and meaning you don't (hopefully) get lots of "why do I have to be john.smith2?" emails.
Please consider this account deleted, I just can't be bothered with the spam anymore.
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
I don't want a middle initial. It was completely useless, if it weren't for filling out forms designed by stupid data collectors.
My father's three names are those of his grandfather, his father and this own given name. Reversing the order of the names to fit into a form is pointless, dropping one is pointless too, and accepting his grandfather's name as his own for the sake of some silly database is too.
It gets worse if you have people whose names don't follow the "a name consists of exactly one word" rule. What's your rule to convert Antonio dell'Acqua into an email address?
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.
Those people should probably not correspond from their university email, and instead sign up for a Gmail account. It's free, you know.
DRM: Terminator crops for your mind!
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
The s sounds pretty easy to guess, could it by student? This would allow for different categories of staff and students based on that letter.
At my university it was abc0 where the abc were the student's initials and the 0 being the increment. I was jfc3.
Funny, my university email IS a gmail account for schools.
it's a username I was able to pick from several suggestions when I initially enrolled for computer account access at that university.
I have seen a conflict on middle initial as well, and the system is taught to put an X instead. Yes, really, an X. When that happens, the user is not really happy, and in that case they get to choose an e-mail address. The format is firstname.lastname@domain.tld but the only mandatory part in the username is lastname to be exactly what the user's lastname is.
Example: jonathan.swift@domain.tld comes in first, gets this username. Then we have Jonathan Andrew Swift who gets jonathan.a.swift@domain.tld. When Jonathan Abbott Smith comes in, he gets the loathed jonathan.x.swift@domain.tld, which he can request to be manually changed to jon.swift@domain.tld (if he wishes that). None of them can, however, have their lastname changed from "Swift" to... "Swifty", for example.
Generally, the initial e-mail addresses are automatically assigned but then people can ask for those to be changed manually, and they will be changed if the requested usernames are available.
The funny stuff comes when you have people from latin countries (Spain, Mexico stand out) where (I think because of legal requirements) the system would generate e-mail addresses such as Jesus.Perez.Antonio.Cristiano.Homero.Hernandez@domain.tld - and yes, that happens quite often.
...gis sdrawkcab (usually not responding to ACs; don't bother posting as AC)
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.
Call them all "Marklar". The individual will be clear by the context.
It must have been something you assimilated. . . .
The simplest solution is to use their student ID or student information system identifier (numeric usually and not their actual student ID).
Example: student_id@domain.tld, with the display name assigned to be the student's name.
It's a bit ugly though.
My university address, which I think still works, is:
First.Last04@[university].ac.uk
Since I joined in 2004. The numbers cut down the number of collisions. Had I stayed on and done a PhD (or been employed) they would have also given me the address without the 04.
This has the additional advantage that it's no problem to offer email forwarding, since no future student's name will collide.
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
But I've seen a kind of "artificial" middle initial, where the first John Smith gets the email address john.smith@organisation.tld, the second becomes john.a.smith@organisation.tld, the third one john.b.smith@organisation.tld etc.pp.
My early big-systems computing life was with the e-mail system at Dartmouth that went to real names in the 80's. There were twenty thousand-ish users and there definitely were a few name collisions with the First.M.Last standard.
There were two solutions. First was a user-editable nickname field. Just a space separated list that could be used to add to matching rules.
So, I had a proper e-mail left part of 'William.P.McGonigle' but my nickname field consisted of 'bill wpm skynet photographer sigep' to help other people find me. Only the real address was guaranteed unique but for phone conversations I could tell people wpm@ (it was unique at the time). People could get me at my machine name that way, look me up in the directory, address me as bill.mcgonigle, etc. (it would combine all dot separated parts with nicknames and department names to find matches).
So, if there were 20,000 people happily using this system, there were four people who it didn't work for, and those were people with the exact same name as somebody who was already on campus. The usual choice was to adopt a different middle initial, use a full middle name, or to accept the nickname as the real first name.
Now, there was always a contingent of people (I won't say aspy nerds because that would be rude) who insisted that those were WRONG and that the addressing scheme had to work exactly the same way for everybody. They probably advocated bmcgo654@ for my e-mail address. But what they missed was that the utility of the system that was in use was so high that it greatly outvalued having a 'perfect' system that had very low utility.
If we lived in a world where every e-mail user could easily query the other institution's LDAP and not run the risk of spam, then that might be fine. But we don't, so easy to use addresses makes the computers easier to use.
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
Nothing looks more professional than bob_smith72@example.com
Give a man a fish, he'll eat for a day, but teach a man to phish...
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.
And for the people that don;t want yet another part of their identity being sent across the internet for all to see?
How about people that don't WANT their middle initial transmitted to everyone they email with?
they obviously want the name to be there.
you could make the same argument about usernames too.
world was created 5 seconds before this post as it is.
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. :-)
I feel your pain, my name is an unpronounceable symbol.
Cheap storage VM.
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.
Fuck you. You're "Prince." Deal with it. ;)
My name is a hyperintelligent shade of the colour blue.
The simplest solution is to use their student ID or student information system identifier (numeric usually and not their actual student ID).
Example: student_id@domain.tld, with the display name assigned to be the student's name.
But Simple is probably not in the vocabulary of a university that let their address space balloon to 350 Domains in the first place.
Seriously, how does something like that happen?
But you have to ask, why bother setting this up at all?
EVERY student entering college these days already has an email address (or maybe 3 or 8).
It would seem the only people that benefit from a numerical student ID based address would be the school administration, so that they could send email to all students without having to think, or even bother to look up the IDs in the on line records. Yet college administration are the one group most capable of looking up everyone in an on-line database, so why do they need a numerical ID?
Just use the student's existing Email address.
In the mean time, consider that not every student WANTS a publicly known or guessable email address.
Most students don't know, and probably shouldn't have to know anyone else's student ID number.
There are benefits to the school of NOT maintaining a huge mail server when other sources will do this for free. First of course is the cost, second the policing that is required.
F. Robert Jack
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.
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.
I've seen that too, but using uncommon letters first, such as z, y, x, q. This was in a government department.
--
no sig for you. come back one year.
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?
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.
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.
.
kjh8037 @ school.tld was the fucker I got in college... completely useless.
Oh, and you had to call support to change your password... you told them the password over the phone for them to set it..
Fun times.
Even now in 2013 they store passwords for the alumni network in clear text in the database... so ify ou request a password reset they email you the password.
[Title.]First.[MI.]Last[Increment]@domain.tldr
I've seen a lot of posts now advocating an OPTIONAL increment appended. Or, optional middle, and when there's a conflict, and optional other thing jacked in.
My only suggestion - whatever format you go with, don't have optional parts.
For example, you should not end up with: ...etc...
john@domain.tld
john.smith@domain.tld
john.a.smith@domain.tld
john.a.smith2@domain.tld
If you expect a large user base, go with the full format for the auto-generated. The above list would then be:
john.a.smith101@domain.tld
john.a.smith102@domain.tld
john.a.smith103@domain.tld
john.a.smith104@domain.tld
Then there's no complaints from one to the other. Even better, people emailing those people won't get to the wrong person when they email "john@domain.tld", because that address won't exist.
After the auto-generated email is handed you, then you can allow "special" people to reserve or alias other names. For example, if one of the VP's is a "john.a.smith", then give him it without the number, and with a 1. Notice, the numbering above started at 101... that reserves 100 low numbers for somewhat special people to make them feel more important :-)
(personally, I'd drop the middle initial. Too many people don't have one, or have two, etc... and you end up with odd series of dots and/or concatenated names)
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!)
People like short email addresses. Do intials plus a random number.
mjs54@domain.tld
Not all initials are good initials, some people will have offensive phrases or sexual innuendo's... I would know, I am one of those.
It's not like the world needs all that many highly-educated John Smiths anyhow. Bonus: Automatic improvement to diversity scores.
not necessarily the best... but at least it was low collission rate
As far as I can tell, and the OP since he asked the question, there is no one "best solution" for this problem.
Example: jonathan.swift@domain.tld comes in first, gets this username. Then we have Jonathan Andrew Swift who gets jonathan.a.swift@domain.tld. When Jonathan Abbott Smith comes in, he gets the loathed jonathan.x.swift@domain.tld
What happens when Jonathan Xavier Smith enrolls?
He gets jonathan.smith, obviously. But what happens when Jonathan Xavier Swift enrols?l
Preaching to the choir, but this is what happens when the powers that be think it's a great idea to remove divisions or subsidiaries from the email address.
These comments are my own and do not necessarily reflect the views or opinions of my employer or colleagues...
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.
jonathan.xa.swift, according to the algorithm. It's just that X has a higher priority than a double-char entry. Damn those recurrent if-then-else loops :)
...gis sdrawkcab (usually not responding to ACs; don't bother posting as AC)
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.
Sure, just make sure that you assign the CEO, whatever VP is in charge of IT and similar roles with firstname.lastname3@example.com and see how quickly the policy gets changed.
From a job security point of view, you should probably send out "proposed new addresses" as opposed to actually assigning such things in the real world.
Give a man a fish, he'll eat for a day, but teach a man to phish...
kjh8037 @ school.tld was the fucker I got in college... completely useless.
Say what you want, but I bet you got a lot less spam than someone whose name was, for example, john.jones @ school.tld
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
It's work-related addresses. Creativity, humour and fun are not relevant here (arguable exception if creativity, humour or fun are your business). Most people have mail clients that automatically recognise addresses in your address book, so length doesn't really matter.
Allowing variations on the order of components should help to drop the collision rate towards the negligible. Potential collisions should be fixable by a semi-automated process, particularly if the recruiting department collects the information early.
Birds are not dinosaur descendants;birds are dinosaurs, for all useful meanings of "birds", "are" and "dinosaurs"
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)