In providing email services, the GI CRC faces the same challenge as any email service provider in balancing security, privacy, and functionality. These factors determine the procedures that are implemented on our servers. Procedures are also influenced by publicly available documents on best current practices for servers that outline both system configuration and ethics for administrators. Finally, specific procedures may be required by policy documents issued from the UA and GI administrative bodies.
The CRC will provide an email account to anyone affiliated with the GI, provided that the client does not have a prior history of abusive behavior on the network. The CRC will establish one or more email aliases for everyone affiliated with the GI who has an email account, even if the account is not maintained on the GI servers.
Our mailservers are currently configured to handle mail for several generic domains including 'gi.alaska.edu' and 'iab.alaska.edu'.
Each email client will acquire an alias of the form :
A users personal email account is considered private, and no one can be given access to another person's account without explicit permission from the owner. However, we can create a 'role' account if shared access to incoming email is desired. A shared account cannot be directly associated with a person's real name.
We cannot provide any guarantee of privacy on email to users and it is inadvisable to make assumptions about the security of unencrypted email messages. However a system administrator must respect the legal privacy expectations of users, and is bound by ethics to avoid infringing on the privacy of clients.
The system administrator of the mailserver is frequently called upon to diagnose email problems and has mail system log files as the primary resource. For each message the system records the date and time, sender and recipient addresses, and subject line in a separate file. In particular, this data is not private and it is the responsibility of the administrator to review and assess it.
When a user has an email issue that requires the administrator to examine a specific message then the complete header information from the message usually yields sufficient information for diagnosis. In some cases it may be desirable to examine the content of the message also, but the administrator should seek explicit permission from the user to do so in each instance.
The mailservers have the capability to accept or reject connections from remote machines attempting to transfer messages to the GI based on the name and IP number of the remote machine. In addition the server can accept or reject messages based on sender and recipient addresses.
Procedures established on the mailservers supplement any policy set by the network manager. The latter may further restrict network access to or from the mailservers, in particular for machines outside the GI network.
The mailservers allow retrieval of messages by clients via the POP and IMAP protocols. These services are restricted by the IP number of the remote machine.
Clients outside the UA network must use the secure versions of the POP and IMAP protocols. These protocol variants are sometimes called POPS and IMAPS, and conceal username and password data with encryption. Inside the UA network both the unencrypted and secure versions of these protocols are supported.
The mailservers act as a 'relay' for outgoing mail originating on other GI users' machines, that is to say the server is neither the source nor destination of the message. This relay service has to be restricted to avoid abuse of the server. The GI/CRC mailservers are configured to allow relay for client machines internal to the UA network. External clients should use a relay provided by their local ISP.
Spam and malware (e.g. advertisements, phishing, and viruses) are detected by filtering the content of each message. The former is treated as a nuisance and the latter as a threat, according to the following procedures.
Identifying 'spam' is not an entirely objective process and hence subject to error. The GI servers are configured to mark a probable spam message for easy identification but continue to deliver the message. A user may request that these be filtered out on the server, or choose to implement filtering on their own client machine.
Malware is malicious software, typically delivered as an email attachment and designed to exploit some vulnerability on the recipients machine. When a message containing a suspicious attachment is identified it is quarantined or discarded. In particular, the recipient should not receive the message, and there may be no notification of the delivery failure to either sender or recipient.
Our goal is to eliminate nuisance messages while preserving legitimate correspondence. The mailserver administrator has responsibility for reducing any undesirable traffic.