| ||||
|
|
|
||
| ||||
|
| |
|
|
|
||||
This document describes, in a general way, the operation of Mount Holyoke College's email system. It does not provide specific information about how to configure or operate your email client, which you can find here.
Our email system serves three basic purposes:
No matter what else we do, we must adhere to a set of international standards which govern the format and transmission of email. These standards are articulated in their respective RFC's, namely RFC821 and RFC2821., which define a messaging protocol referred to as SMTP, for Simple Mail Transfer Protocol.
Email server software which is written to comply with the SMTP standard is referred to as an MTA, for Mail Transfer Agent. The MTA we use for SMTP communications is Sendmail. We have several SMTP servers on campus, each serving a different purpose. The primary servers are as follows:
An email sent from a desktop client will first go the server called 'smtp'. This server then relays the message to 'mgate', where it will pass through our virus and spam filters. If the recipient is on campus, the message then goes to our mail hub, 'mail.mtholyoke.edu'. This is the server your mail client retrieves your email from.
An email destined for an off-campus address also goes from your email client to 'smtp', then to 'mgate'. After that, rather than being delivered to the mail hub, it is relayed to the recipient's mail server.
If you are off-campus, you can also send mail through the Mount Holyoke College system, but you have to authenticate yourself. This is something you can configure in your mail client. Again, your email goes from your email client to 'smtp.mtholyoke.edu' (after your email client has authenticated itself to this server). From there the message is relayed to 'mgate', and then to either our mail hub for Mount Holyoke recipients, or the off-campus recipient's mail gateway.
We defend against spam and viruses at our mail gateway. We employ a number of tools and techniques which drastically reduce the number of undesireable messages entering campus:
The nexus of our defensive efforts is MIMEDefang. MIMEDefang exposes Sendmail's built in "milter" mail filtering API to the Perl programming language. It provides the framework which other tools, like SpamAssassin and ClamAV, plug into. It also provides a number of its own filtering functions. For example, we use MIMEDefang to check the validity of recipient addresses (is the recipient a valid MHC user?). Messages sent to invalid recipients are bounced back to the sender. As this check happens before the body of the message is even seen, it saves a good deal of processing load.
We are able to identify as spam and block approximately 1/3 of all email attempting enter campus using some in-house code which implements a technique called 'greylisting'. Greylisting works as follows. The sender and recipient couplet of every incoming message are used to key into our greylist database, which is kept in RAM for fast lookups. For example, when Wile E Coyote sends me an email, the lookup key might be <wile@acme.com><rpeterso@mtholyoke.edu>. When an email arrives, if its greylist key already exists in the database, the message is delivered without further delay. If the address couplet does not exist in the greylist database, then we temporarily reject the message with a TEMPFAIL message. This message is sent from our email server to theirs, and simply means "I can't accept this right now, please try again soon." This failure message is a standard component of the SMTP email protocol. Legitimate SMTP mail servers understand and comply with this failure code. They will dutifully resend the message, at which point the mail will be accepted and the address couplet will be added to the greylist database.
The reason this stops so much spam is that illigitimate mailers, such as spam bots and viruses, are not bona-fide MTA's, do not implement the full SMTP protocol, and will not reply to temporary failure notices. The only consequence on our end is that the first time someone sends you an email after the greylist database is refreshed, the message may be delayed a few minutes.
SpamAssassin is a project now run by the Apache organization, the same folks who write our web server software. SpamAssassin defines a huge number of weighted rules, to which we add some of our own, which are applied to each incoming message to ascertain the probability that it is spam. With very few exceptions, we do not use these rules to reject email outright. Rather, we add additional headers to each message which indicate SpamAssassin's spam probability assessment. As an end user, you can then employ these headers to filter mail yourself. For example, you might configure your email client to put all messages where the header X-Spam-Score: has a value of 4.5 or higher into a folder called 'probably-spam'. This way, it won't clutter up your inbox, but it's still around, in case a valid email is tagged as spam.
We also maintain an extensive list of access controls to block spam from know spam relay sites and other problematic senders.
We address the virus nuisance in a couple of different ways. ClamAV is a virus identification program that plugs into MIMEDefang. ClamAV identifies message attachments as viruses by comparing them against a signature database which is updated daily. If ClamAV makes a positive identification (usually several hundred per day), the message is bounced back to the sender with an explanatory message.
If a message attachment makes it past ClamAV, it will still have its name modified to have a '-VirusRisk' extension if it ends with .exe, .com, or any number of other file extensions which connote executable status in DOS. This helps discourage people from the engaging in the ill-advised practice of running executable email attachments simply by clicking on them.
Email that makes it past our spam and virus filters is delivered to our mail hub, known as mail.mtholyoke.edu. The MTA on this server (Sendmail) is responsible for deciding how to deliver mail to the specified recipient(s). The recipient might be an MHC username, the name of a maillist, or an alias.
If a recipient address corresponds to an MHC username, the message is then typically deposited in that user's INBOX. Other actions might also be taken, according to configuration settings in that user's ~/.forward file, and possible username expansions defined by the system's global aliases file. For example, you may configure your .forward file to accept the local delivery, while also forwarding a copy to another address elsewhere. Or you might configure your .forward file to automatically respond with an away message using the 'vacation' program.
In addition to your INBOX, where incoming mail is deposited, you have a folder in your home directory called /mail. This folder serves as a central repository for other email you might have. This might include sent messages, drafts, and messages that you file away according to whatever scheme suits you.
So now that your email has found a way to be saved to disk somewhere, how do you get at it? We provide support for a variety of access methods. You can access your email using text based email clients ('pine', soon 'mutt') available via your interactive login shell. You can access your mail using either the POP (on-campus only), IMAP, or IMAPS (secure imap) protocols, which is how you would configure an email client like Mozilla Mail or Outlook Express, for example. Or you can view your email using a web-based interface (which uses the IMAP protocol behind the scenes to access your mail files).
With the exception of POP, all of these methods maintain the central organization of your email INBOX and ~/mail folder. You can use them interchangeably, without one affecting the other. The POP protocol can cause trouble, as it will move your email from our mail server to the computer running the POP mail client. Sometimes this is what people want, but usually it is not. For desktop client configuration, prefer IMAPS, unless you have a compelling reason to use a different protocol. IMAPS is secure (all data, including your username and password, are encrypted during transmission), and will maintain the integrity of your central mail store.
When configuring a POP or IMAP email client (e.g. Mozilla Mail), you may have noticed you need to specify two different mail server names. You need to use the name 'mail.mtholyoke.edu' to refer to the server which handles your saved email, both the mail in your INBOX, as well as what's filed in your ~/mail folder. The name 'smtp.mtholyoke.edu' is the name of the server your email client must use to send email.
Note that the server smtp.mtholyoke.edu is only available to send mail for computers which are on campus. You can not use Mount Holyoke College's email server from off-campus to send email. This is typical of all well-managed email installations. The reason for this is to prevent outside parties from using our email servers to masquerade their identities. If we did not do this, it would be a trivial matter for outside parties to use our infrastructure to send huge quantities of spam, for example.
When you are off-campus, you need to do one of two things to be able to send mail. You either need to configure your email client to use your ISP's (Internet Service Provider) SMTP server for outgoing email (contact your ISP for details), or you need to configure your computer with VPN client software which will enable you to establish a secure encrypted tunnel to the Mount Holyoke College network.
Note that the files containing your email are readily accessed using basic filesystem operations. If you log on to mhc, your INBOX can be found at /var/spool/mail/yourusername. The rest of your email is in ~/mail. You can look at your mail files with the program 'less' if you'd like to see what they look like. If you want to keep a personal archive of your email, just copy your INBOX and your ~/mail folder off-line. Burning them to CD is good way to create a personal backup.
Home | MyMHC | Web Email | Directories | SiteMap | Search | Help
Admission |
Academics |
Campus Life |
Athletics Copyright © 2006 Mount Holyoke College. This page created and maintained by Ron Peterson. Last modified on February 3, 2006. |