The CC mail system is a general purpose mail server, accessible through several Internet standard protocols. All modern computers have desktop applications that support these protocols directly. Examples are: Microsoft Outlook Express, Netscape, Eudora, and Pegasus. All you have to do is to fill in the information for the CC mail system and then start your mail client. Here are some common settings:
IMAP (or POP) server: mail.cc.umanitoba.ca
SMTP server: mail.cc.umanitoba.caYou will also have to fill in your own e-mail address, of course. If the mail client offers both POP and IMAP access, IMAP is generally a better choice.
You may already have an e-mail application included with your web browser. Click here to try this e-mail reader.
There is now a web application that will allow you to read and send mail with your web browser alone. Before trying it, be sure that your web browser has both cookies and Java enabled. Beware also, that an e-mail web application is likely to be slower in response than an e-mail application running directly on your personal computer. The effect will be more noticeable with if you have a slow Internet connection.
On 11 February 2007, the CC e-mail server electra was upgraded to version 2.3.8 of the Cyrus IMAP server software, in preparation for the next stage of the mail system upgrade.
On 25 March 2007, it was converted from a conventional IMAP server to a combined proxy and storage server. At the same time, the new e-mail server castor was brought into service as an IMAP storage server. Castor is a Sun T2000 server with a single eight-core CPU and 16 gigabytes of memory. The Solaris 10 operating system is installed on mirrored disks. For storage it uses one terabyte of high performance disk space on our Netapp file server, through a connection to the iSCSI SAN. This space was later expanded to 2 TB, with the final expansion to 3 TB completed in January 2010. IMAP files are stored on a ZFS filesystem, providing high performance and reliability, and dynamic sizing. Daily ZFS snapshots are available for quick restores of deleted files.
Between 7 April 2007 and 21 April 2007, all of the IMAP mailboxes that resided on electra were migrated to castor. This process was generally invisible to e-mail users because electra acts as a proxy to forward IMAP connections to castor.
The front end server electra is a Sun Fire 480 with quad 1200 MHz CPUs and 16 gigabytes of memory. The Solaris 9 operating system is installed on mirrored disks. Logs, databases, and other such data reside on a Sun SE3310 high performance disk array.
Beginning in October 2008, the e-mail front end was migrated to a Sun X4450, a 16-core Intel x86 server running Solaris 10. This process was completed in July 2009.
The CC mail system uses the latest version of the Cyrus IMAP and POP server, along with the latest version of the sendmail SMTP server. The Cyrus IMAP server is a scaleable enterprise mail system designed for use from small to large enterprise environments using standards-based technologies. Cyrus differs from other IMAP server implementations in that it is run on "sealed" servers, where users are not normally permitted to log in. The mailbox database is stored in parts of the filesystem that are private to the Cyrus IMAP system. All user access to mail is through software using the IMAP or POP3 protocols.
Another new feature is Sieve, an Internet standards-track protocol for filtering messages on delivery. The Cyrus Sieve implementation supports filing messages into specific folders, forwarding messages, rejecting messages, and the standard vacation function. It can reply to messages based on headers or envelope information.
Both Cyrus and sendmail also offer improved security through the authentication mechanisms provided by the SASL library. Currently, support includes: LOGIN, CRAM-MD5, DIGEST-MD5, NTLM, and STARTLS.
As promised, the initial mailbox quota for new users is now 50 megabytes for students and 300 megabytes for employees and guests. All quotas that were below those new settings were increased to meet them. These initial settings were recently doubled, making them 100 and 600 megabytes now.
Mailbox quota increases will be handled in the usual manner. The next step is 100 megabytes for students and 600 megabytes for employees and guests. Increases to this level will be granted on request. The final step is 200 megabytes for students and 1200 megabytes for employees and guests. As before, increases to this level will require justification.
These steps were recently increased to 200 and 400 megabytes for students, and 1200 and 2400 megabytes for employees and guests.Some of these pages contain links to the secure server. These will be noted as `secure' in the text. In addition, any page on this web server can be accessed through the secure server (SSL security) by adding the prefix `/secure' to the URL. For example, http://mail.cc.umanitoba.ca/alpha/beta.html uses the standard server, but http://mail.cc.umanitoba.ca/secure/alpha/beta.html will use the secure server.
Unfortunately, an incoming e-mail message does not contain enough information to make a positive identification that it is spam. Consequently, any technique that attempts to reject spam automatically will only reject some of the e-mail spam, and will also reject a certain amount of legitimate e-mail. The trick is to employ several such techniques that are moderately effective at discriminating between the two.
The CC mail system will reject incoming e-mail if the domain portion of the sender's e-mail address is not a registered domain name. This means that if the spammer forges `getrich@04438.com' as the origin of the mail, our server will reject it. The server also rejects mail from misconfigured mail clients, so that if you specify your address as `USER@cc.umantioba.ca', your mail will also be rejected.
The CC mail system also rejects e-mail with an unqualified sender address such as `getrich', rather than `getrich@yahoo.com'.
A great deal of spam originates from Internet accounts with large Internet Service Providers such as bellsouth.net or orange.fr. We use a number of `spam trap' e-mail addresses to detect spam from these sources. The addresses, which are widely advertized but do not belong to individuals, feed the mail into a system that determines the origin of the message, and automatically sends a complaint to the abuse handling address at the appropriate ISP. They, in turn, investigate the complaint and take action against the sender of the e-mail.
We are now running the Distributed Checksum Clearinghouse (DCC) spam blocking system on our CC and MS mail systems. You can read more about DCC at the DCC web site The DCC is essentially a system for detecting bulk e-mail, that is mail consisting of multiple copies of the same message, rather than for detecting spam. Both e-mail spam and legitimate mail from mailing lists have the characteristic of bulkiness. The difference is that spam is unsolicited, but people request to be added to mailing lists.
You may notice a new header line that has appeared in most of your mail. It's added by DCC, and looks something like this:
X-DCC-UofM-Metrics: electra 1032; Body=many Fuz1=many Fuz2=many
The portion after the semicolon lists three checksum types and the count of copies of mail with these checksums seen by the DCC servers. If any of the three counts are greater than the threshold, currently 100, or are the word `many', the message would have been rejected by our mail server. This system is very effective in detecting e-mail spam.
Our DCC spam control system also uses the Spamhaus ZEN blacklist to detect spam. ZEN is a list of IP addresses that focuses on the hordes of compromised home computers all over the world that are now the major source of spam. You can read about ZEN at the Spamhaus web site. We have a contract with Spamhaus that permits us to obtain an updated copy of the ZEN database every 30 minutes.
E-mail rejected by ZEN will still be listed in each person's bulk mail summary, and can be whitelisted in the usual way. Since the ZEN check is done before the bulkiness check, a great deal of bulk mail will be rejected by the ZEN check. These two checks are essentially independant measures of spam. Having both of them working together should reduce the amount of spam that most people get.
The DCC spam control system also provides a greylist facility. This is very effective, blocking over 30% of incoming e-mail as spam. It works by reporting a temporary delivery failure during the SMTP dialogue with the sending system. E-mail senders that comply with the SMTP standards will place the message in a queue, and retry delivery later, usually within ½ hour. Spam broadcasters, on the other hand, tend to ignore SMTP response codes and never retry delivery. The DCC greylist keeps track of delivery attempts, and will accept the e-mail on the next attempt. It also remembers sender and recipient e-mail address pairs, and will accept subsequent e-mail messages with that pair on the first delivery attempt, without introducing a delay. This facility generally works automatically, and does not require intervention by senders or recipients.
There can be may reasons for this to happen. Network problem or mail server problems somewhere between the origin and destination of the mail could cause a delay. Most mail systems will send a `delayed delivery' report back to the sender of the e-mail if they are unable to deliver it within a few hours. If they still can't deliver it after several days, they will send back a `delivery failure' report.
Another reason could be the dreaded `hotmail double bounce'. Free e-mail services such as Hotmail have a size limit on incoming mail. If you send a large e-mail message to one of these services (or to someone who has their e-mail forwarded to such a service) the mail server will return it to you with an `oversize mail' report. However, if your e-mail is also forwarded to such a service, the mail server won't be able to deliver the returned mail either, and will be forced to discard it. In this case, you will have no indication of why the mail disappeared.
The CC mail server allows SMTP clients to relay mail to any destination, provided that the client is on one of our campus IP networks. Clients on foreign networks can only send mail to local destinations, unless they authenticate prior to sending the mail. This is a standard practice used to prevent spammers from abusing our mail servers to relay spam. SMTP clients can authenticate simply by checking or reading their mail via POP or IMAP up to half an hour before sending mail.
The CC mail server also supports authenticated SMTP, which is a feature of most most e-mail clients, and makes the process more transparent. Authenticated SMTP does require a userid and password for sending mail, just as POP or IMAP requires them for reading mail.
The Trend Micro InterScan VirusWall e-mail scanner is no longer running on the CC mail server. Viruses contained in e-mail messages will appear similar to attachments in normal e-mail messages. If they are also not detected by an anti-virus product running on the workstation computer, they may be activated by the computer user. Unless it's disabled, the security zones included with the computer operating system should detect the malicious software. Typically, it produces a message like ``Some files can harm your computer''. This message should generally not be disregarded.
The usual reason for this problem is that you have exceeded your quota of mail storage space on the CC mail server. By default, students have 100 megabytes of space, and employees have 600 megabytes of space, for the INBOX and other mail folders. Once this quota is exceeded, the mail system will no longer deliver new mail, although it will keep it in a queue and attempt to deliver it periodically. Once you have deleted some old mail to reduce you space usage below the quota limit, new mail will begin arriving again.
Some POP clients will not show you old e-mail that you have already read, although it still occupies space in your INBOX. So, it may appear that your mailbox is empty, and you still do not get any new mail. These programs usually have an option to show the old e-mail, and once you find that, you can delete the mail.
Some IMAP clients will not show you messages that you have deleted, but will keep them in your mail folders. They will have an `expunge' or `compress mailbox' action that will finally delete the messages.
The Cyrus IMAP server does send quota information to the IMAP clients, but unfortunately some common IMAP clients do not display this information. This makes it easy to exceed your quota without knowing about it.
The main reason to use IMAP in preference to POP is that IMAP overcomes many of the annoying limitations of POP. A POP client can only access e-mail messages in your INBOX, and only one POP session can be active at a time. With IMAP, you can have a number of mail folders, all stored on the mail server, and can access them with more than one session simultaneously. You can also read or delete messages individually with IMAP. POP requires you to download the entire mailbox before doing anything with it. IMAP also makes it much easier to have a consistent view of your mail folders while accessing them from more than one location.
Much of the functionality of IMAP is dependant on the IMAP client, so if you don't like the way that IMAP works, try a different client.
I'm so glad that you asked that question. If you log in to CC Unix, subscribing to class `mail' instance `inbox' will give you a Zephyrgram whenever mail is delivered to your INBOX on CC. You can also be notified of Cyrus sieve activity, such as mail forwarding, by subscribing to class `sieve' instance `*'. Here's an example of how to do this with `zctl'.
$ zctl ZCTL $Revision: 1.21 $ (Protocol ZEPH0.2) - Type '?' for a list of commands. zctl: retrieve Class message Instance personal Recipient your-id@CCU.UMANITOBA.CA Class mail Instance inbox Recipient your-id@CCU.UMANITOBA.CA Class mail Instance biff Recipient your-id@CCU.UMANITOBA.CA Class operations Instance message Recipient * zctl: file .zephyr.subs zctl: add sieve * zctl: retrieve Class message Instance personal Recipient your-id@CCU.UMANITOBA.CA Class mail Instance inbox Recipient your-id@CCU.UMANITOBA.CA Class sieve Instance * Recipient your-id@CCU.UMANITOBA.CA Class mail Instance biff Recipient your-id@CCU.UMANITOBA.CA Class operations Instance message Recipient * zctl: quit