Special Email Addresses for Departments and Units

Personal email addresses at UIC are of the form netid@uic.edu. However units, departments, and other entities on campus often have need of task-oriented email addresses that are should not be identified publicly with a specific person, for handling student's queries, help desks, and the like. The ACCC provides three alternatives for these departmental, non-personal email addresses. All three include (a suitable choice of) an uic.edu email address and all must ultimately be owned by a specific person, though that person can be changed as personnel and duties change.

All three have different strengths and limitations. Please consider all three alternatives.

• Listserv Email Lists
• GoogleApps Groups
• RT: Request Tracker
• Email Aliases
• Non-Personal Accounts are not an option

The purpose of Listserv electronic mailing lists is to redistribute incoming email to its subscribers. For departmental uses, these subscribers could be a few people who will answer the incoming email sent to the list or a selected list of (many) people who should receive official email sent from the list. The list's owner or owners can manage the list's configuration -- add or remove subscribers, specify who can send or approve email for the list, and many other things. Listserv lists can be configured to accept email from subscribers only or to accept email from non-subscribers as well, and to limit the non-subscriber email to email specifically from UIC or from anywhere in the world.

At UIC, Listserv email lists have the email addresses listname@uic.edu, where the listname can be up to 15 characters in length and supports dashes and underscores.

The following set of Listserv options works nicely if you want the public to be able to send email in and a select group of people to answer the incoming email:

• Anyone (limited to people on campus if you wish) can send email to the list.
• Subscription to the list is by the list owner only.
• The only subscribers are the people who are authorized to answer email sent the list.

Any email message that is sent to this type of Listserv list will then be sent to all of the people who can answer the message. You can assign people specific people to answer the messages by day or week. Or a person can pick up a message to answer and send the reply to back to the list also, letting the other subscribers know that the message has been taken care of.

Listservs lists are also good if you want to send out official email messages to a group of people, by the way. Then you use these options:

• Only the list owner or owners can send email to the list.
• The subscription the list will by the list owner only, with the listowner specifically adding all the people who need to receive the messages to the list.

Limitations:

• Because a reply to a request sent to a Listserv list will come from the individual subscriber's email address, not the list, the list does not provide a central tracking place for responses to incoming messages.
• It can be hard to keep track of whether individual incoming messages have been answered.
• Both of these problems can be mostly taken care of if the subscribers always send copies of their replies to the list and use the Listserv list's email address as the Reply to: address in their reply email messages. Most email programs can also be set up to use alternate From: addresses.

For more information:

For more information about listservs and to request one, see Listserv Discussion Lists at UIC.

A Google Group is a collaboration tool, as well as an email discussion group that comes with its own Web page to read the email sent to the Group's address. While anyone with a UIC GoogleApps account can set up a personal Google Group based on their own netid, ACCC will accommodate requests for special GoogleApps Groups for official purposes with a departmental-type email address.

Limitations:

• Each member of the Group must have their own GoogleApps@UIC account in order to access the Group via its GoogleApps Web page. However, Group members do not have to have a GoogleApps account to receive or send email to the group.
  
  
• The GoogleApps other than Gmail -- and this includes the Google Group Web pages -- have significant accessibility problems.

For more information about GoogleApps Groups and how to request an Official GoogleApps Group, please see: GoogleApps@UIC: Using Google Groups. (In particular, please note the special instructions in Official Google Apps Groups at UIC.)

Best Practical's RT: Request Tracker is an email and Web-based system for submitting, replying to, and tracking individual requests. This is how it works.

1. A member of the public sends an email message to the email address that is assigned to your RT queue.
2. RT opens a ticket using the email and sends the user back a welcome message with a link to the Web page for the ticket.
3. RT moves the message into your RT queue. Members of your staff will have been authorized to access the RT tickets in your queue; RT can also send copies of each new ticket to selected people via email.
4. Replies to specific RT tickets can be made
   • by email by anyone, or
   • by using the RT Web page for the ticket; access to the Web page is limited to the ticket's requestor, assigned interested parties, and your authorized staff members.
5. RT keeps track of all correspondence for the ticket in a centralized location while still allowing each authorized user to access and interact with it using his or her own login credentials.

RT might sound overly formal, and but it is very easy to use, very flexible, and doesn't involve using anyone's personal email address. Login to the RT Web pages uses Bluestem, so everyone uses their UIC netid and passwords; there aren't any additional login ids or passwords.

The email addresses for RT queues are name@uic.edu. Usually the name, like a netid, is 3 to 8 characters in length, letters and numbers only, but longer names with dashes and underscores can be arranged when necessary.

Limitations:

• There is some work in getting an RT instance set up.
• The people replying to RT tickets probably will want to learn how to use the RT Web page.

For more information:

For more information about RT and instructions on how to request an instance for your department, see RT - Request Tracker for Departments and Groups.

An alias is a netid without an actual account associated with it; however, each email alias must have a owner -- a faculty or staff member -- and will be listed as a "secondary netid" on their ACCC account. Email sent to an alias@uic.edu must be sent some actual email address for delivery. This is useful for email related to a specific purpose, which has only one intended recipient, who may change periodically. To allow for the continued use of a departmental email address even if an employee leaves UIC, the owner of the alias can to change mail routing as needed.

Email aliases are netids -- 3 to 8 characters in length, letters and numbers only.

Limitations:

• Aliases can route to only one email address, which will likely be an individual's personal email address.
• Because email coming into aliases is actually distributed to and replied to from the recipient's individual email address, it is hard to share the correspondence and to keep it impersonal.

More information:

To request an alias, send an email message to accounts@uic.edu with the following information.

• alias name
• alias owner (must be faculty or staff; they will be able to change the recipient email address)
• recipient email address (can be different from the owner)
• alias title (example: "ACCC Accounts Group").

People often ask us for actual email accounts that could be shared by several people. But sharing an account requires sharing a username and password, and ACCC policy forbids that as does the official policy of the University of Illinois Office of Business and Finacial Services (OBFS).

Specifically, the OBFS Policy Manual, Section 19.5, Information Security Policy, "Access Control Policy" states:

"Access to the network and servers and systems should be achieved by individual and unique logins, and should require authentication. Authentication includes the use of passwords, smart cards, biometrics, or other recognized forms of authentication.

As stated in the current campus policies on appropriate and acceptable use, users must not share usernames and passwords, nor should they be written down or recorded in unencrypted electronic files or documents. [...] All users must secure their username or account, password, and system access from unauthorized use."