| Effective date | January 2002 |
| Version number | Version 5 |
| Last updated | 28 May 2013 |
| Policy owner | ICTS |
| Policy approved by | UICTC |
Table of contents
Background
UCT implemented a new email system, Novell GroupWise, in 2006. As part of the conversion from the old system to the new, UCT implemented a naming standard for UCT email addresses approved in 2002 via Principal's Circular (PC 01/2002).
Email addresses are made up of two parts separated by "@": local part @ domain.
An examination of existing UCT email addresses showed that a standard existed only for student addresses: student number @ mail.uct.ac.za.
Staff addresses, on the other hand, varied widely in format:
- first initial surname @ Novell server or virtual domain.uct.ac.za
- surname initial @ Novell server or virtual domain.uct.ac.za
- organisational unit initials @ Novell server or virtual domain.uct.ac.za
- given name @ Novell server or virtual domain.uct.ac.za
- surname @ Novell server or virtual domain.uct.ac.za
In 2002, a proposal to adopt firstname.surname@uct.ac.za as the naming standard for UCT staff email addresses was approved via Principal's Circular (PC 01/2002). Due to the technical limitations of the IMAP email system, fewer than 50 addresses could be created in this format. During the implementation of GroupWise in 2006, UCT gave effect to the approved policy, such that all staff will have an email address conforming to the approved standard.
Policy details
1.1 |
UCT implemented the following naming standard for UCT email addresses:
|
|
| 1.2 | Domain
Adopting a single domain name "uct.ac.za" for both staff and students offers the following benefits:
|
|
| 1.3 | Local part: students | |
1.3.1 |
The student number (CampusID in PeopleSoft) continues to be used as the local part of the email address for students. This guarantees uniqueness, clearly differentiates a student email address from a staff address, and allows for automatic mailing from systems that contain the student number such as PeopleSoft. |
|
1.4 |
Local part: staff and Post-doctoral fellows For staff, the local part takes the form of PreferredFirstName.Surname. The information used to derive email addresses would come from SAP, PeopleSoft or the Third Party System. To ensure that other systems can process our email, we must handle special characters as follows: |
|
1.4.1 |
Surnames containing multiple words will consist of the full surname with no spaces. e.g: John van der Merwe will be john.vandermerwe@uct.ac.za. |
|
1.4.2 |
Surnames containing special characters not allowed by the email system will be formatted without the special character. (e.g.: Patrick O' Brian will become patrick.obrian@uct.ac.za). |
|
1.4.3 |
While most systems would accept hyphens or underscores, the "." differentiator has advantages: it is easier to remember, has become widely used, is easier to communicate verbally, and does not become obscured when the email address is hyper-linked with an underline (e.g. jo_andersen@uct.ac.za) |
|
1.4.4 |
Because email addresses aren't case-sensitive, using "." is also a better option than trying to use caps to differentiate between first and last names (e.g. JoAndersen@uct.ac.za). When typed in lower case only, the name becomes difficult to interpret (e.g. joandersen@uct.ac.za). |
|
2. Generic email addresses and mailboxes
2.1 |
Faculties and departments may request generic email addresses. Dedicated mailboxes will be allocated for each faculty (dean) and department (HOD). |
||
2.2 |
Responsibility |
||
2.2.1 |
The accountability and responsibility for generic addresses resides with the Dean/Head of Department/Executive Director or Director responsible for the faculty or department requesting the generic address. |
||
2.2.2 |
It is the responsibility of the faculty and/or the department concerned to validate that they are able to adopt the address and that no conflict with any other faculty or department generic email address exists. |
||
2.2.3 |
Provided that the request has been authorised by a Dean/Head of Department/Executive Director or Director, and no obvious clash or problem exists, the address and mailbox will be authorised and provided. |
||
2.2.4 |
ICTS will only veto a request if it is technically impossible to implement, and/or encompasses another academic or administrative function or service. |
||
| 2.3 | Format of generic email addresses |
||
2.3.1 |
Vice-Chancellor and Deputy Vice-Chancellors
|
||
2.3.2 |
Academic functions
|
||
2.3.3 |
PASS departments and university-level functions For example:
|
||
2.3.4 |
Functional offices
|
||
2.4 |
Existing Generic Email Addresses |
||
2.4.1 |
Where generic email addresses have been implemented as aliases to selected accounts, such addresses will be retained and linked as an alias to a dedicated mailbox associated with a standardised generic email address upon request. |
||
2.4.2 |
Published generic email addresses which do not conform to the standard must be replaced by an address which conforms to the generic email address standard outlined above. |
||
3. Maintaining existing email addresses
3.1 |
Aliases to existing email addresses can be established, so that email messages sent to the old addresses aren't lost. However, this should only be maintained for a limited time. The simplest and most cost-effective solution would be to use the existing email system infrastructure to forward mail to new addresses for a minimum of twelve months. |
3.2 |
After the 12 month period, the email system could generate automated replies to people who have sent mail to old addresses, to inform them of the new email address naming standard implemented a year previously and to provide a URL for obtaining current UCT email addresses. |
Additional Information
Factors considered when creating this naming standard
All email address formats have advantages and disadvantages. The table below describes important factors to consider in evaluating the various options.
| Uniqueness | Each address must be unique; therefore, the naming standard should minimise duplications. |
| Personalised | Addresses should depersonalise users as little as possible (e.g. an address containing only numbers is less personal than one containing a name). |
| Intuitive | Addresses should be easy to guess and remember, and should not be too long. |
| Unchanging | Addresses shouldn't need to be changed when the organisational structure changes (e.g. when a department changes names) or when a user takes on a new post in the University. |
| Administrative costs | The management (creation, deletion, editing) of email addresses for both staff and students should be automated to reduce administrative costs and improve accuracy. Costs can also be lowered by having unchanging addresses. |
| Risk of error | Addresses should not cause confusion about the identity of the addressee, or make it likely for someone to receive another's email. |
| Institutional image | Addresses should present a professional image. |
| Internationally acceptable | Addresses should follow international standards to the extent required to ensure that other email systems can deal with UCT's mail. |
Advantages
Uniqueness & degree of personalisation
- The standard minimises the number of duplicate names that would occur, and personalises addresses as much as possible.
- Using both a given name and a surname generates far fewer duplicates than standards that use less information such as surnames with or without initials, given names only, etc. The SAP data (at the time of implementaion) indicated that given name.surname would lead to 31 duplicates, out of 5404. Using a preferred first name instead (e.g. Andy instead of Andrew, Thanda instead of Thandabantu) would reduce some of these duplications, personalise the address and make it more intuitive.
- Using full initials.surname to handle the first duplicate eliminates the number of conflicts to none (again, based on SAP data, which may not be perfectly accurate). This is preferable to attempting to include both a given name and an initial. A format such as naomi.g.jacobs@uct.ac.za that includes two full-stops would prevent automation.
- The least personal addresses, which include a number, should occur very rarely.
- To personalise the address, name changes (due to marriage for example), would be allowed.
Intuitive
- The given name.surname is widely used internationally.
- Using names rather than numbers, both a first and a last name, and a preferred first name rather than a "given name" makes it much easier for a sender to accurately predict and remember a recipient's email address.
Unchanging
- Email addresses would only need to change when an official change of name has taken place (e.g. marriage or divorce). An alias could be created and maintained for six months to the old email address. The time period needs to be brief, so that fewer duplicates are created while additional old addresses are being maintained.
Risk of error
- Errors occur when senders guess addresses incorrectly. By including both a first and last name, this should happen less frequently than it would if less information was included.
- Errors are most likely to occur in the rare case of an email address containing a number.
Administrative costs
- The naming standard allows for the highest level of automation, thus ensuring consistency, accuracy and lower administrative costs.
Amendments to this policy
May 2013
The Operations Management Advisory Group (OpsMAG) and other UCT fora discussed the matter of a suitable naming standard related to generic mailboxes (for deans, HOD's and so forth). As a result, the Enterprise Content Management and Email Project Implementation Committee in collaboration with the Registrar amended section 2 of this policy to include specific information regarding generic email addresses and mailboxes. The amendment was approved by University Information and Communication Technology Committee (UICTC) in May 2013.