NOTICE: All KSoC Email service will be switching to campus UMail on May 6th, 2024.  Please see Transferring KSoC Email to Campus UMail for more information.

 

 

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.

General Overview

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 example@cs.utah.edu, where example is your chosen username. Email should not be sent to any other address, such as , example@mymachine, example@cs, or . To authenticate for IMAPS/SMTPS please use your NIS/LDAP username and password. (I.e., example and NOT example@cs.utah.edu.)

Along the same lines you should not attempt to mail example@eng, example@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 shortcuts 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 below 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.

Please read the following for details on how to set up your email clients, Spamassasin is a program which identifies spam and tags it according to common and user-customizable rules. Once tagged, it is easy to use procmail to refile mail or manipulate it in any fashion you wish. (You can access instructions under the E-Mail FAQ menu on the support page, information on Maildir format, and IMAP support.) Also included is information on how to set up certain files that will allow you to customize how email is delivered, identify spam, and set up automatic replies when you go on vacation.

Client Setup

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 with 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 refer to your ISP for the proper 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.) Please be aware that some clients use the “IMAP NAMESPACE” feature to find this information on their own and should not have the prefix entered manually. The Mac OS X client is one example which uses this feature.

Allowed Attachments

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.

Webmail Access

If you wish to access your SoC email via the web, you can use our webmail client at https://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.

Common Customization

 

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. The shell.cs.utah.edu systems are *nix servers designed specifically for interactions like this.

• Procmail
  
  All email that comes into the SoC facility is actually written out to disk via a program called procmail. It’s default behavior is to deliver email into your ~/Maildir directory, although you can configure it to do pretty much whatever you like. There is an on-line FAQ, as well as man pages for procmail, procmailex, procmailsc, and procmailrc. Note that you must not have group or other write permissions enabled for your home directory and your .procmailrc, or procmail will not process your file for security reasons.  The .procmailrc file does not exist by default, you must create it.
• Forwarding email
  
  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
:0: forward.lock
*! ^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 recipe continues processing other 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. 

• Vacation
  
  Vacation is a method for alerting people that you are away from email for an extended period of time. You can access detailed instructions with this link, or under the E-Mail FAQ menu on the support page.

• Spamassasin
  
  Spamassasin is a program which identifies spam and tags it according to common and user-customized rules. Once tagged, procmail can be used to manage the email in any way you wish. You can access detailed instructions with this link, or under the E-Mail FAQ menu on the support page.

• maildir2mbox

  This program converts mail that is currently in Maildir format into mbox format. Its use is a bit awkward, as instead of taking command line arguments, you must provide maildir2mbox configuration information by setting three environment variables. The man page for maildir2mbox covers its configuration and use.

• mb2md

  This program pulls mail from a conventional mbox file and places it into your ~/Maildir directory in the proper format. Unfortunately, mb2md does not have a man page, but its use is very easy to understand. Run ‘mb2md -h‘ to see the program options. In addition, you can find out more information at the mb2md homepage.

IMAP

Our IMAP server runs Dovecot-IMAP, which uses the open Maildir standard. You can use Maildir aware 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. (The now obsolete mail 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 or your local system, you will have to open this port for your email client.

Maildir Format

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 is written out as individual files, one per email, to a suite of sub-directories in the directory ~/Maildir, rather than being stored in a single monolithic spool file. This aids in preventing problems with file-locking, specifically over NFS, as the email server is not fighting with the user’s client for access to the mail spool.

You should not try to edit, move, or rename files or sub-directories in your ~/Maildir directly! This can lead to loss of email, errors in receiving or sending email and other issues. Always use your email client to delete and refile email, as it will perform these actions through the email server, preventing these issues.

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. (See maildir2mbox and mb2md above.)

One effect that having mail delivered into ~/Maildir is how interactive shells notify users of incoming mail. Most shells (tcsh, bash etc.) by default will look for mail in /var/mail/username, and will notify you when new mail is discovered. For example:

[61] belay:~:> echo "foo"
foo
You have 1 mail messages.
[62] belay:~:> 

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, set the MAIL environment variable (export MAIL=/home/username/Maildir) 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.

Disk Quota

An important factor in having your email stored in ~/Maildir is that your email counts against your quota.

If you exceed your quota, incoming 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’ on shell.cs.utah.edu or any other SoC administrated system.

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.

Mailing Lists

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 our mailman server to see all the public lists we serve. (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 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 support ticket, by sending email to .  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.org site. 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 email for list owners follows the format, <listname>, where ‘<listname>’ is the name of the list in question.) 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.