Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

I'm looking for best practise suggestions here.

What are the reasons for and against using role names as email account prefixes versus the user's name? I.e.

"reception@domain.com" vs. "mary.jane@domain.com"
or
"developer13@example.com" vs "john.smith@example.com"

And additionally, are there any special cases where the 'general rule' should not apply? Like for certain roles? eg. "reception", "contact", "helpdesk", "admin"??

I just need more awareness of the pros/cons so I have more to go to management with.

share|improve this question

9 Answers 9

up vote 8 down vote accepted

The main reason for role addresses is people change jobs.

It's much easier to change a mail server alias so reception@ or sales@ points to the new staff member or a team's mailing list than to contact every client that has ever received that address and request they change their address books.


Addition for clarity:

From a business perspective, clients want make sure they can always get in touch with someone to help them, yet have access to specific staff members for client/account management or higher level support/sales when appropriate.

To achieve this goal, my recommendation is to use both both techniques; staff should have personalised/named accounts, and be members of a alias or mailing/distribution list for their department, role or branch -- whatever delineation makes sense.

What address is given out or used then becomes a business decision of expected follow up / personal contact / historical knowledge required, staff turnover and how "general" client requests are (example, password resets can be performed by any helpdesk staff member)

For front line customer-facing roles, departments with high turnover or where requests can be completed by any staff member, clients can be provided the alias (support@, sales@, reception@) for that department, guaranteeing someone from that department will receive their mail and be able to look after them. When a staff member leaves or changes role, it then becomes a matter of changing the alias or mailing list subscription.

For roles where a high level of personal contact, historical knowledge, or where the work can only be performed by specific staff members, contact can be made using the named account. I'd recommend the client should be provided with an alias address as well so they are not left out in the cold when a staff member leaves the company or is on leave.

share|improve this answer
1  
To add to this, we have a very high turnover rate at some of our positions. These positions are usually very remedial, but require direct contact via email from our customers. We'd rather not let our customers know that yet ANOTHER CSR is helping them, so we use logins based on the position name instead of the actual person's name. Not only does it give our customers a peace of mind, it makes the job at IT much easier. –  Russ Warren Jul 7 '09 at 12:45
    
The money spent doing the whole "redirect so-and-so's email to the person who replaced him" routine is crazy (both in the "change your address books" labor, and in the "add an additional email alias on the server" labor). I don't know why people do it. –  Evan Anderson Jul 7 '09 at 13:17
    
@Greg: I'm not sure what you're advocating exactly here. Are you saying that users should have named accounts and they should be included on alias lists? –  cottsak Jul 11 '09 at 10:27
    
@jimmygee - correct. I've edited my response for clarity. –  Greg Work Jul 11 '09 at 12:09

It definitely depends on the context - named accounts should be for when people would want to communicate to that person specifically (e.g. 'send this file to John in accoutns'), while role accounts are very useful for when you don't care who is currently doing that job, just that they get your message (e.g. 'notify reception that I'm expecting a visitor').

You might even have some people with personal accounts and responsible for, or with access to, role accounts - for example helpdesk workers: customers might intially send email to 'helpdesk@....' and then recieve a reply from 'ann.other@...'. That's how we have it at my company and it works very well for us.

share|improve this answer

I usualy make distributions groups with roles names and put into the group the persons concerned,if there's only one persone i'll do it anyway so there's always one email adress per person and at least one email adress per role.

share|improve this answer
    
+1 for using distribution groups. Makes transition to a new person or including multiple people far easier. –  Kevin Kuphal Jul 7 '09 at 13:27

Personal named account one for everybody, and it doesn't truly matter if you go with firstname.lastname@domain.com or the shorter firstinitial+lastname@domain.com - role-named accounts are unnecessarily demoralizing (nobody wants to feel like they're reception2).

Role-named addresses are great for groups. This lets people send mail to a box that numerous people check, or that gets distributed to a group that is easily managed by you.

  • Purchasing: your supplies still get ordered even if half the department is on vacation

  • Sales: quickest response is a good thing

  • Helpdesk: same

  • US-Employees, Contractors - HR loves time-saving groups like these, to help them send out benefit information to the right subgroup

Finally, if you hook these addresses to a central-directory logon at some point in the future, everyone will NEED a distinct account that is traceable to only them, so you can manage permissions and auditing correctly.

Bear in mind that generally, if someone wants to send email as Sales, rather than send out their own name in the return-to address, that'll be possible by granting send-as permissions.

share|improve this answer
    
If multiple users receive the same request (from say a customer) becsuse they are all on a group/alias list, how then do you manage who "has the ball" with that query? What stops two users (both from the same list) responding to the customer? –  cottsak Jul 11 '09 at 10:30
    
Some kind of workflow system? Could be as simple as flagging the message with a different color for each person, or moving it to individual "in process" subfolders. If they're each just viewing the same shared inbox (probably best) - could definitely get messy if it's sending a duplicate to each person. –  Kara Marfia Jul 11 '09 at 23:08

There's a reason email aliases were developed. They make it much easier when people change roles.

for certain roles? eg. "reception", "contact", "helpdesk", "admin"??

RFC 2142 gives a list of email addresses one should reasonably expect for any domain.

share|improve this answer

I would definitely NOT use role names. Just my two cents, but when people have a role account and not their own personal account they tend to share it around and give out the password. If that's not a problem then go for it~

It's also easier to manage a group-based infrastructure in my opinion. Make groups for those roles and assign individuals.

Also, what do you do when someone changes roles? Happens a lot where I work~

share|improve this answer
    
You don't think you could maybe assign aliases or have more than one email address per person? –  RobM Jul 7 '09 at 13:08
1  
I don't buy the argument, but then I don't assign "generic" user accounts to people either. In an Exchange environment, I use distribution groups to give individuals additional "role addresses". The user still uses their own individual AD user account, but their membership in these groups (of which, typically, there is only one member) gives them the additional email addresses. –  Evan Anderson Jul 7 '09 at 13:18
    
I don't understand what you don't buy? You don't like my method but then detail the exact same thing? Maybe a misunderstanding of terms? –  Tim Green Jul 9 '09 at 11:36

There are no "best practices". It's all down to what is decided for any particular organisation. With that in mind, The only time I see role based email addresses is for generic roles, where frequently more than one person handles that email. e.g. support@someplace.org

I think you'll find that in general most people and companies prefer to use name based email addresses. Of course there's no "standard" for how they are generated. You'll see every conceivable combinatiuon of names and initials, either all joined together or separated by a dot, dash or underscore.

My suggestion is to give careful consideration to the role each person has and whether that role is or will be performed by multiple people, who will all access the same email account. Choose an email address as appropriate.

share|improve this answer

We use role based names for general accounts, "applicaiton_support@domain.com" or "sales@domain.com". These accounts are often shared by several people. There are normally used for initial contacts when people don't have a specific person to contact.

share|improve this answer

To throw some cents in here:

Every user gets an individual account and email address. Users who work in "role" positions (purchasing, support, etc) are encouraged or required by policy to use the "role" address when performing their "role" duty. (The individual accounts are necessary to allow auditing of individual user activities.)

I particularly like to use role accounts in vendor relationships. I like to have things like:

  • Microsoft.Volume.License.Contact@xxx.domain.com
  • Symantec.Support.Contact@xx.domain.com
  • etc

I've been the contractor filling in for departed sysadmins on many, many occasions, and having to go thru a long list of vendors removing and replacing the old sysadmin is a complete waste of time.

I wouldn't constrain this to IT vendors. I'm just using them as an example. In the end, flexibility in controlling the delivery of future emails and decoupling "the role" from "the person" are good things.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.