|Written by Scott Ostrander|
|Thursday, 02 February 2006 04:34|
Electronic mail, outside of networking and machine uptime, is probably the most important service that the School of Computing (Soc) Facility provides. This document is meant to instruct users in the basic use of email in the SoC Facility. It is not meant as an exhaustive compendium of information on email, its use, client features, etc.
Most communication both inside and outside of the SoC, including the Facility's trouble ticket reporting system is handled over email. Email is regarded as an official document by the University of Utah and is covered under the University of Utah Policies and Procedures manual accordingly. Due to its importance, the SoC Facility email infrastructure is comprised of several machines, sharing responsibilities and providing for continuation of service in the event of any specific machine failure. The following material will provide in simple measure all of the information needed to interact with this distributed system.
There are a couple of basic things you should know about your email account here in the SoC Facility:
Your email address is firstname.lastname@example.org. Email should not be sent to any other address, such as , johnqpub@mymachine, johnqpub@cs, or. To authenticate for IMAPS/SMTPS please use your NIS/LDAP username and password. (I.e., username and NOT email@example.com.)
Along the same lines you should not attempt to mail johnqpub@eng, johnqpub@sci, etc. Doing such will result in undefined behavior.
Email which is not fully qualified will potentially bounce, or may be delivered to unexpected destinations. If you would like to set up short cuts for email addresses, most mail clients support aliases or some form of an address book.
Your email is stored in a directory called Maildir that resides in your home directory (e.g./home/username/Maildir). Email within this directory is kept in Maildir format. You should not edit, copy or move any of these files by hand, as you will risk damaging the integrity of your email. (There are programs that will allow you to manipulate your email within that directory, see the Maildir section for details.)
You can access your email using clients that access your ~/Maildir directory directly, or via IMAP. Which method you use is merely personal preference and will sometimes be dependent on what client you wish to use and whether or not you work from home or other remote location.
In general, if you only read email from within the school, a client which directly manipulates your Maildir directory is well suited. If you plan on accessing your email remotely with any frequency, you should consider an IMAP client.
Conversely, we only support sending mail from a utah.edu email address (including any subdomain of utah.edu). If you want to send email from some other domain, please use that domain's mail service.
Your email client, also referred to as a "Mail User Agent" (MUA), is the software used to read and send email from your personal system. You may use any Maildir or IMAP client that you wish to access mail within the SoC Facility. Clients will vary in features and capabilities, so trying out different software packages may be necessary to find one that you like.
In setting up your mail client, you should use the submission port (587) and enable STARTTLS for sending mail on smtps.cs.utah.edu. If your client gives you the option of authentication mechanisms we support 'AUTH PLAIN' and 'AUTH LOGIN'. To read mail use imap.cs.utah.edu via port 993 and SSL/TLS and normal authentication. Most Windows clients will do this automatically for you. (Do not check 'Log on using Secure Password Authentication'.) If you wish to use your private ISP's email address, please use your ISP's SMTP server.
Though most modern email clients will query the server for the correct information, at times it may be necessary to enter some settings by hand. One of the most common is the root folder path/prefix. The root prefix used on our server is "INBOX." (No quotes, and note the trailing period.) For those of you that are running IMAP clients that are not listed above, please be aware that some clients use the "IMAP NAMESPACE" feature to find this out on their own and should not have the prefix entered manually. The Mac OS X client is one example which uses this feature.
If you wish to send an attachment please use a .tar.gz or a .tar.bz2 (compressed) archive. Sending executable attachments and some Windows file extensions, e.g. .pif, will be filtered. Windows archive formats: .zip, .rar, .arc, .arj, .zoo, .7z, etc. will be opened and examined/filtered if they contain restricted files. You can still send python or perl scripts, as long as they are attached as plain-text and not executable files.
If you wish to access your SoC email via the web, you can use our webmail client athttps://webmail.cs.utah.edu. You will be prompted to enter your SoC UNIX username and password (the same one you use to access IMAP directly.) Please note that this is an unsupported service that is available as a last resort if you cannot access your email via IMAP or shell.cs.utah.edu.
Important Note: Special folders, such as drafts, sent and trash are not setup by default! You must go into the webmail settings and set them before the webmail system knows to use them.
For a majority of users, leaving your email environment to its default settings work well enough. However, there are a variety of adjustments which can be made to your email environment to tailor it to your wishes.
Settings for your base email environment are found in various files in your home directory. Remember that this configuration information is not meant to be a comprehensive guide. Links to on-line documentation, man pages, and other places where you can find more detailed information have been provided here. You will find it useful to become familiar with the tools that you are using before modifying your environment. Also please note that the mail servers run *nix. Do not edit your files with Windows' programs or they may be saved in a format and/or with file permissions that will not work with the mail servers.
If you need to forward your email to another address outside of the SoC Facility, edit (or create) a ~/.procmailrc file and create a recipe (replace with your email address to which you want to forward your email):
# forward mail to remote address
*! ^X-Spam-Status: Yes
The line about not forwarding mail tagged as spam is optional. If you'd like to keep a local copy then change the recipe to ":0 c: forward.lock". This means to continue processing recipes and if that is your only recipe, then the default action is to put the mail in your inbox. If you have a more complicated .procmailrc, please read the man pages as this goes beyond the intent of this FAQ.
Spamassasin is a program which identifies spam and tags it according to common and user-customizable rules. Once tagged, it is a snap to use procmail to refile it or do anything else you want with it! You can access instructions under the E-Mail FAQ menu on the support page.
We are using the Dovecot-IMAP server which uses the open Maildir standard. You can use Maildiraware clients and IMAP clients interchangeably. However if your client only uses Maildir as a spool and refiles mail into its own space/format, the IMAP server will not be able to access any mail stowed by the client. (Pine is an example.)
In addition to the new mail format, the IMAP server only supports encrypted connections on port 993/TCP via Secure Socket Layer (SSL/TLS). If you have a firewall running you will have to open this port.
Email in the SoC Facility is stored in Maildir format. This differs from the traditional mbox-style file that exists in /var/mail/username. Maildir format was developed as a part of the Qmail email server suite, and there is quite a bite of documentation available off of the Qmail web site.
The major innovation in Maildir format is that your email gets written out to a suite of sub-directories in the directory ~/Maildir. Traditionally, all your email was stored in a single file, which all applications (your client, the mail server, etc) shared. This caused problems with file-locking, specifically over NFS. Maildir addresses these problems and is also integrated with the IMAP server we are running.
You should not try to edit, move, or rename files or directories in your ~/Maildir directly. Instead, use your mail client to delete and refile email.
If you run into a situation where you need to convert between Maildir format and the traditional mbox format, there are two tools located in /usr/local/bin that can help:
One effect that having mail delivered into ~/Maildir is how shells notify users of incoming mail. Most most shells (tcsh, bash, etc) will by default look for mail in /var/mail/username, and will notify you when new mail is discovered. For example:
 belay:~:> echo "foo"
However, you need to inform your shell that your new mail is in ~/Maildir so it knows the right place to look. For bash users, you just need to set the MAIL environment variable (MAIL=/home/username/Maildir ; export MAIL) and for tcsh you need to set the mail environment variable (set mail=/home/username/Maildir/). Please see the man page for your shell for more information.
An important factor in having your email stored in ~/Maildir is that your email counts against your quota.
If you exceed your quota, your email before email will be bounced back to the sender with an "over quota" message. It is very important that you keep enough quota free to receive messages which are spooled in your ~/Maildir
To check your quota, just run csquota from shell.cs.utah.edu.
NFS and other Dependencies (Re-queuing)
If for any reason your mail cannot be delivered, the server will re-queue your mail for three days before returning it to the sender. For example, if the NFS servers are down, the mail server will re-queue your mail and retry delivery with a back-off algorithm. This also applies to your .forward file. If the mail server cannot get to your .forward because your home directory is not available it will read the file when the filesystem is back on-line.
The software package that we are using to implement mailing lists is called mailman. Its use is straight forward and quite intuitive. Just point your web browser to http://mailman.cs.utah.edu/listinfo for instructions on its use. (This page is only available from within utah.edu address space. Please use our VPN if you need to access the page externally. Note that you can always access a list's page directly from anywhere via http://mailman.cs.utah.edu/listinfo/.) This includes subscribing yourself to a list. You do not need to mail the support queue to be added to a list. Simply subscribe yourself by clicking on the list and following the instructions on the page. If you are faculty and need a list created, please create a ticket. You cannot create a list via the web interface.
You may wish to peruse the User Manual. Additional documentation is located at the www.list.orgsite. And a searchable FAQ is located at Mailman FAQ. Note that if you are having problems with a list, you should first try mailing the list owner, e.g. before emailing the support queue. The list owners have as much control over a list as the support team and solutions to problems might actually be delayed going through the support queue, as we need to contact the list owner for permission to modify their mailing lists in any case.