Astrophysics Research CentreQueen's University Belfast • School of Mathematics & Physics |
|
Some useful tips on the use of the ARC email server.
Overview
The ARC now runs its own email service, in advance of the main QUB service being moved to a Microsoft Exchange system which we do not believe can properly support our needs. The service runs on star.pst.qub.ac.uk, providing secure IMAP and Webmail. There are a near infinite number of email clients out there, and to try to provide instructions on how to use each of those with our server would be impossible. So instead, here are some general guidelines - if you need assistance with a specific client, contact the Systems Administrator.
Servers
All incoming email is stored on star, and webmail comes from there too. However, sending email can be a little more complex. If you are in ARC, then you should use star as your SMTP server, and you do not need to provide a password since we authenticate you against your IP address. If, however, you are outside ARC (eg. at home) then you need to use the QUB SMTP server, which will authenticate you using your QUB Email address and Directory password, the latter being the one you use to - for example - logon to Queens Online. Further details are available on this in the SMTP server section below.
Since we run our own servers, we can afford to be more generous than the main QUB service in terms of mail quota. At this point I am not enforcing strict quotas, but I will start to ask you to trim down your mailboxes when you hit the order of a gigabyte or so - which is pretty generous, and should allow you to keep most of your email on the server in IMAP folders, rather than have to keep some in your client as local folders. The advantage of this is that you can then switch email clients at will and all your mail in IMAP folders will be exactly where you left it, and is even accessible using the webmail service. It's straightforward to move email from local folders to the server, just drag and drop in most clients, so I strongly encourage you to do this. Webmail
Though it would be possible to interface to the QUB Prayer Webmail service, we do not do so since it seems likely Prayer will not be around in the Exchange era. We therefore run our own service, using the SquirrelMail system. This service is quite powerful, but is easy to use and seems to work well in most browsers.
You logon to the webmail service using your regular logon name for the ARC network (eg. rsir) and standard password. The first time you use the service, it will prompt you to enter your full name and email address - for the latter you should specify your full QUB email address, eg. r.ryans@qub.ac.uk. If these are not specified properly then the server will reject your email - any mail leaving QUB must be tagged with a QUB account as sender. The first time you visit the webmail site from a given computer your browser will almost certainly issue a warning about the security certificate used to encrypt the SSL link - this is because I have generated a 'self-signed' certificate. This just means that no third party is vouching for our identity, but that's not a factor since the only people using this service are ARC members. Your browser should let you accept the certificate anyway, and will usually offer the option to accept it permanently, avoiding having to deal with this each time. The exact procedure varies between browsers and operating system, but it's generally not that hard to work out - if you are having problems, let me know. IMAP service
Most of the time when you are reading your mail, you will be doing so using one of the various IMAP clients that are available. These include PINE, KMail, Thunderbird, SeaMonkey's Email module, Mail.app, etc. All use the standard IMAP protocol and so should work just fine. Again, given the range of clients and configurations it's impossible to give more than general guidance on setup.
Required settings for all email clients:
As with the webmail service, most email clients will object to our self-signed certificate when it is first presented to them. Again, it is safe to tell the client to accept the certificate permanently. SMTP service
Your mail client also needs to know what servers to use in order to send email. Unlike the IMAP service, which SMTP server you use depends on where you are accessing the network from. If you are within the ARC network then you use star - otherwise you must use the main QUB SMTP service, which requires authentication.
Within the ARC, the only settings you need to give your mail client for sending mail are:
Mailing Lists
We have several mail aliases on star, which make it easy to send email to groups of people within ARC. Note that these aliases will only work if you are using star as your SMTP server, or are using our webmail service. The aliases are:
Other email aliases can be set up on request. It is possible to use both internal and external email accounts with these. Message filtering
All mail incoming to QUB is scanned at the central mailhubs before being passed on to the ARC servers. Any message found to contain a known virus is rejected (a bounce message is sent to the originator so they know you did not get the email, in case it was a genuine email). All messages are also processed by the SpamAssassin software which adds a tag to each email rating how likely it is that the message in question is spam. You can setup filters to route likely spam either to a designated spam folder on the server, or else automatically delete it. This is accomplished using the powerful procmail package.
To understand how filtering works, you must first understand how mail is stored on the server. If you SSH into star you will see that your usual home area is not present - instead all you are likely to see when you type ls is a single directory called Maildir. Within Maildir you will see three subdirectories, called cur, new, and tmp - this is where your IMAP Inbox mail is stored - read messages are stored as individual files in cur, new messages within new (obviously), and tmp is a temporary directory used by the mail server. Other server mail folders are also stored within Maildir, but by default you don't see them since their names all are prefixed with a full stop, which means they are not shown with ls unless you use the -a flag. For example, here is what I see in my own Maildir directory: [rsir@star ~]$ ls Maildir cur dovecot-uidlist new tmp [rsir@star ~]$ ls -a Maildir/ . cur .Research.Programming .. .customflags .Research.TLUSTY .Computer Stuff.APS .Deleted Messages .SciFi .Computer Stuff.Email dovecot-uidlist .Sent .Computer Stuff.nam08 .Drafts .Sent Messages .Computer Stuff.OS X Intel .holding .Site Registrations .Computer Stuff.Purchasing .INBOX .Spam .Computer Stuff.QUB Admin .Logwatch .subscriptions .Computer Stuff.ROSA new .Temp .Computer Stuff.Software Licenses .Personal.Ferrets tmp .Computer Stuff.Warranty .Personal.iTMS .Trash .Contacts .Personal.Shopping .Useful links .Cron .Research.FLAMES Anyway, when filtering, we want to identify some element in the incoming message which will let us decide where what folder it should be directed to, instead of going directly to the Inbox. There are many, many, filtering options in procmail, and those are outside the context of this document (a good source of procmail recipes is here), but luckily simple filtering based on the SpamAssassin spam score is easily done. When SpamAssassin has analysed a message it adds its spam score to the message headers - if you set your email client to show full message headers you will see something like this: X-Spam-Score: ++++++ (+6.4) X-Spam-Score-Int: 64 procmail's instructions are held in a file called .procmailrc in your home directory on star. A simple file which filtered all emails with a SpamAssassin score of 4+ to a folder 'Spam' at the top level of your IMAP folders would look like this:
# Sample .procmailrc file
# Setup some basic parameters - these must be here.
# The logging is optional, but advisable until
# you are confident your filters are working properly!
# The log is written to procmail.log in your home directory
SHELL=/bin/sh
MAILDIR=${HOME}/Maildir/
DEFAULT=${MAILDIR}
LOGFILE=${HOME}/procmail.log
LOG="--- Logging ${LOGFILE} for ${LOGNAME}, "
# The order of the recipes is significant - the first one that matches
# will be executed and that's it, the email is routed!
# Spamassassin filters
# Anything at 4+ will be routed to the Spam folder
:0
* ^X-Spam-Score: \+\+\+\+
.Spam/
# Accept all the rest to the default mailbox
:0
${DEFAULT}
The problem with this is that all spam messages get routed to the Spam folder, and it becomes tedious to sort through it regularly. Once you become more familiar with SpamAssassin you may well decide that any message you get with a spam score over, say, 6 is certainly rubbish and can be automatically deleted, while anything remaining above 3 is probably spam but worth keeping to check over. To do this, we'd amend the .procmailrc to this:
# Sample .procmailrc file
# Setup some basic parameters - these must be here.
# The logging is optional, but advisable until
# you are confident your filters are working properly!
# The log is written to procmail.log in your home directory
SHELL=/bin/sh
MAILDIR=${HOME}/Maildir/
DEFAULT=${MAILDIR}
LOGFILE=${HOME}/procmail.log
LOG="--- Logging ${LOGFILE} for ${LOGNAME}, "
# Spamassassin filters
# Anything at 6+ will be deleted
:0
* ^X-Spam-Score: \+\+\+\+\+\+
/dev/null
# Anything 3 or less will be saved
:0
* ^X-Spam-Score: \+\+\+
.Spam/
# Accept all the rest to the default mailbox
:0
${DEFAULT}
Once you have a .procmailrc file, you then need to create a .forward file, which is the file that tells the mail server to route all messages to procmail. This is quite simple - a plain text file containing the line: "|IFS=' ' && exec /usr/bin/procmail || exit 75 #rsir" Since this may all be a bit much to process, I have created a few template files which you can modify to suit your own needs. All you need to do is logon to jennyquantum, then
Vacation autoresponders
If you are going to be away for a while, and unable to read your email, you may want to setup an automatic responder to let people know when (if!) you will be back. This can be done with procmail. The rest of these instructions will assume that you have already setup spam or other filtering using procmail as described above - if not, you need to setup the .forward and a basic .procmailrc file as described there (you may delete or comment out the lines for spam filtering if you don't want to enable that).
There is probably no point in auto-responding to every single email that comes in - for example, responding to spam is at best a waste of time, at worst a confirmation to the spammer that the account is live. For this reason, the best place to insert an auto-responder is probably after your spam filters, but before any others you have created. The code itself is a little complex, but can be simply copied and pasted into place, with one single edit needed to enable it in most cases. Here it is:
# Vacation autoreponder ##############################################################
# path to file containing generic reply message to be sent back.
REPLYFILE=$HOME/vacation.msg
# path to file where seen e-mails are logged
# should clear out this file when disabling vacation services
CACHEFILE=$HOME/vacation.cache
# Set variable to contain my email address
MYMAIL=r.ryans@qub.ac.uk
# Rule to write sender to vacation.cache file, and send a vacation
# note back to the sender unless they're already in the cache file.
#
# Manual formail limit of 8192 bytes on the cache file, which may need
# to be set higher depending on diversity of e-mail recieved.
# Note: To avoid sending vacation notices to addresses that spammers
# have forged, consider adding a "* !^X-Spam-Status: Yes"
# qualification if using SpamAssassin to tag potential spam.
:0 Whc: vacation.lock
* !^FROM_DAEMON
* !^X-Loop: $MYMAIL
| formail -rD 8192 ${CACHEFILE}
:0 ehc # if the name was not in the cache
| (formail -rI"Precedence: junk" \
-A"X-Loop: $MYMAIL" ; \
cat ${REPLYFILE} ; \
) | $SENDMAIL -oi -t -f $MYMAIL
# Vacation autoreponder ##############################################################
Below are some notes on setup issues with specific clients.OS X Mail.app
In Mail.app, you will be presented with the dialog box complaining about the server SSL certificate until you permanently install it into the system.
To permanently accept a self-signed SSL certificate:
PINE
For all you diehard PINE users, here's how to setup PINE to work within ARC...
First, from the main menu select Setup (s) and then Configure (c). Then set the following fields, replacing rsir with your own username as appropriate.
user-domain = qub.ac.uk
smtp-server = star.pst.qub.ac.uk
inbox-path = {star.pst.qub.ac.uk/novalidate-cert/user=rsir}INBOX
..scroll down...
customized-hdrs = From: Robert Ryans <R.Ryans@qub.ac.uk>Nickname : star Server : star.pst.qub.ac.uk/novalidate-cert Path : View : SquirrelMail
Squirrelmail can exhibit unusual ordering of messages when sorting by date, if you have copied your emails from another server to star using KMail or Thunderbird.
The problem is caused by the way SquirrelMail does date sorting. Most mail programs examine the message headers, and sort the messages based on the arrival time listed in those headers. However, SquirrelMail seems to rely on the mail server to do date sorting for it. The problem with this approach is that each email is kept in a separate file on the server, and the server performs date sorting based on the file creation date. When emails are copied over from another source their file creation dates are set to the time the messages were copied, which will obviously not match the message arrival time in the mail headers. New messages arriving on star are fine, but older ones will be bulked together. If you are experiencing this issue, let me know - I have a script which can fix the file creation dates to match those in the message headers. As a matter of interest, Apple's Mail.app copies messages over while preserving the modification date, since it seems to use the same server-side sorting by default. |
Quick Links
|