Follow Slashdot stories on Twitter


Forgot your password?
Communications IT

Ask Slashdot: Name Conflicts In Automatically Generated Email Addresses? 383

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)?"
This discussion has been archived. No new comments can be posted.

Ask Slashdot: Name Conflicts In Automatically Generated Email Addresses?

Comments Filter:
  • Re:a few ideas (Score:5, Interesting)

    by ssam ( 2723487 ) on Thursday January 31, 2013 @12:37PM (#42751741)

    also remember that its lots of fun to receive email (and post) intended for someone else in your company with the same (or similar) name. especially if you are a student, and they are a professor.

    (i guess its why we have and for staff)

  • by Anonymous Coward on Thursday January 31, 2013 @01:16PM (#42752241)

    My daughter was born in another country (Australia), her last name is my name and her mother's name with a hyphen in between.

    The consulate of my country (Belgium) did not accept double names, so they only put my name on her passport.

    When my daughter and her mother returned to my country a couple of months before I did, the local community (Schaerbeek) had a conflict with the ministry of foreign affairs and they were doing a boycot action: they unlawfully did not recognize any foreign birth certificates, so they inscribed my daughter under her mother's name and denied to recognize that I was her father.

    I took us about 3 years before that mess was sorted out. Until then she had 3 different official last names.

  • by gnasher719 ( 869701 ) on Thursday January 31, 2013 @01:24PM (#42752343)
    Here's a solution to this problem: If there is more than one John Doe, you change them _all_ to john.doe followed by a random but unique three digit number. john.doe itself is redirected and automatically gives a reply containing the list of correct john.doe email addresses plus some information that makes them identifiable.

    So if I wanted to email John Doe in accounting, I'll get an email back telling me the CEO is john.doe386, there is john.doe196 in accounting, and the janitor john.doe412.
  • by bill_mcgonigle ( 4333 ) * on Thursday January 31, 2013 @03:02PM (#42753531) Homepage Journal

    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.

  • by BenEnglishAtHome ( 449670 ) on Thursday January 31, 2013 @03:19PM (#42753753)

    Where I last worked, there were over 110K employees and we had plenty of people sharing the same name. Here's how it went.


    Same names:

    Still the same: Senior employee got Junior employee got

    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. :-)

Civilization, as we know it, will end sometime this evening. See SYSNOTE tomorrow for more information.