Depends on what you mean by the term "reference". If you mean "should I track them in the CMDB"? Then I'd say absolutely not, let Exchange or what ever your email tool is, can do that. You could use a person record to store that information also by integrating with your email system.
I did use some text 255 fields to store some group email lists associated with CIs for the purpose of contacting folks in an escalation.
If I miss understood what you are looking for, please restate the question or issue you are looking to solve. I'll check back.
1) treat the email account as an attribute of a person; 2) treate the email account as a CI, which is then related to a person.
I suppose that the vast majority of organization choose option 1. However, suppose you are an ISP and managing email accounts is part of your core business. Suppose, too, that a single person might have multiple email accounts, or that you need to track and manage all sorts of attributes of email accounts. In this context, it might make a lot of sense to treat email accounts as CIs.
Remember, the CMDB is supposed to be the reference database for the way things OUGHT to be configured. You mail server only documents the reality, which may or may not be correct or authorized.
Thanks for the answers. I know that mail accounts can be an attribute of the person or a CI releted. The question is: why could be interesting for me to declare e-mail accounts as CI's and not as a simple attribute?
Hi Dani, Take into consideration the following: 1. Probably you already have an E-mail Admin working with a dedicated tool to create and manage E-mail accounts for all users. 2. Handling an attribute is easier than an entire new category of CIs(e-mail accounts in this case)!This could be done using Work Orders and associated "planned status" facility to update "E-mail Address" field during distributed change process. So, these are some reasons for why is better to use simple attributes instead of new category of CIs. There is any doubt?! Kind regards, Dan