Personal email addresses at UIC are of the form NetID@uic.edu. Units, departments, and other entities on campus often have need of task-oriented email addresses that should not be identified publicly with a specific person.
Technology Solutions provides several options for these departmental, non-personal email addresses.
Policy
Please note that in compliance with the University Information Security Policy:
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.
and with Technology Solutions' Acceptable Use Policy, which disallows password sharing, we do not provide shared accounts. Instead, choose from one of the following options.
Email Alias
An email alias - alias@uic.edu - can forward messages to a single existing email address. Email aliases are not accounts and do not have passwords associated with them. An alias allows for continued use of an email address even if a person leaves UIC, as ownership of the alias can be transferred from one person to another without changing the published email address. To request an alias, email accounts@uic.edu and provide the following:
- Alias name (3 to 20 characters in length; letters, numbers, underscores, and hyphens only)
- Who will own the alias and who will receive messages addressed to the alias (owner can manage email routing but owner and recipient can be different)
- Purpose or intended use of the alias
Limitations
- An email alias can route to only one email address, which in the simplest form will likely be an individual's personal email address.
- Because email sent to an alias is actually distributed to and replied to from the recipient's individual email address, it is not the solution of choice when communication is meant to be shared. (See one of the options below for services that work better for shared communication channels.)
Listserv Email List
A listserv supports multiple recipients (subscribers) and can accept messages from subscribers as well as non-subscribers depending on how it is configured. Listservs have both listname@uic.edu and listname@listserv.uic.edu as their email addresses. Listserv names can be up to 15 characters in length and support letters, numbers, underscores, and hyphens in the name. Listservs can be created online by UIC faculty and staff. A Listserv can be configured with the option for accessing archives online.
Limitations
- Because a post to a Listserv address will come "From" the sender's own email address on behalf of the Listserv rather than "From" the Listserv itself, responses directed to the sender instead of to the Listserv are not tracked or included in the archives.
- It can be difficult to keep track of whether individual incoming messages have been answered.
- Both of these issues can be mostly taken care of if the Listserv is configured to use the Listserv email address as the "Reply-to" address and subscribers always send copies of their replies to the Listserv address.
Exchange Shared Mailbox
A
shared mailbox is a mailbox that multiple users can use to read and send email messages. Shared mailboxes make it easy for a specific group of people to monitor and send email from a common account.
Users authorized to access a shared mailbox log in with their own NetID and password, but email sent to and from the shared mailbox uses an address reserved for the shared mailbox in the form mailboxname@uic.edu. When a person in the group replies to a message in the shared mailbox, the email appears to be from the shared mailbox rather than from the individual user.
Request a shared Exchange mailbox.
Limitations
- All persons accessing the shared mailbox must have a UIC Exchange Online account to be accessed with their own NetID and password.
Google Group in UIC G Suite
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. Anyone with a UIC G Suite account can set up a personal Google Group based on their own NetID by themselves. Technology Solutions will accommodate requests for special Google Groups for official purposes with a departmental-type email address. A UIC G Suite account is not required to send or receive email from a Google Group, but it is required to create and manage a UIC G Suite Google Group.
Limitations
- Although people without a UIC G Suite Gmail account can send and receive email through the Group's email address and subscriber list, Group members who want to access the UIC G Suite Group's web page and online email archives must have a UIC G Suite account to log in to the website with their own NetID and password.
- The G Suite apps other than Gmail -- and this includes the Google Group web pages -- have some accessibility limitations.
Request Tracker (RT)
Please note: RT is deprecated and no new instance requests are being fulfilled, as the university transitions to a new ticketing system.
Request Tracker (RT) is a web-based system for submitting and tracking email messages (requests). It is intended for high-volume email addresses and allows groups and departments to manage multiple email addresses in one place. RT is similar to a shared email account, but each person uses their own credentials (UIC NetID and password) to access it. There are two ways to interact with RT: by email or via its web interface. Email discussions related to a specific request are easily tracked with a ticket number appearing in the subject line of the emails as well as in the ticket's own web interface. A UIC email address is not required for interacting with a ticket by email. Request an RT instance.
Limitations
- When an email is sent through an RT ticket the sender's identity is not automatically shown in the email header. If the sender does not identify themselves in the body or signature of the email it may be necessary to use RT's web interface to identify the sender.