URCS Department Mail Server Upgrade 2006 Wiki

Watch this space for information about the the mail server upgrade as it becomes available.

Mail Service Upgrade Scheduled Downtime

morning 06/06/2006

Mail Service Upgrade Benefits

Better mailserver hardware performance

Greatly improved system and userlevel spam controls

Better Imap connectivity

Imap Service Users

differences for imap users explained here:

Mailbox folder prefix settings

Mailbox folder prefix is no longer necessary. This is the directory inside your home directory that the imap server will look for (and index) saved mail folders. The current imap server will by default try to index your toplevel home directory. The new server will look for saved mbox format mail folders in ~/mail. After the new mail server goes live you should clear the mailbox folder prefix from your mail client before connecting. It may be set to "mail/" if it is it should be cleared and left blank.

Webmail:
If you have specified a mail folder prefix in webmail options you should change it there as well. If you haven't used webmail or set any specific options the correct thing will happen if you connect after the upgrade.

Known Imap Issues With Some Mail Clients

APPLE USERSApple Mail Users:

If you are a MAC user, and want to use the Apple Mail program, you must use the version that comes with OSX 10.4 "Tiger" Mail.app version 2.x or after. Older versions of Apple Mail that are included with OSX 10.3 "Panther" have well known problems with contemporary IMAP servers. We cannot support Apple Mail prior to version 2.x. If you are unable to upgrade your operating system to get the latest version of Apple Mail we urge you to download and use the freely available Mozilla Thunderbird as your mail client. If you still choose to use the defective version of Apple Mail it is at your own risk.

Mail.app by default indexes and caches every piece of saved mail both in the spool and in saved mbox folders in your home directory. This enables integrated desktop search capabilities on your Mac desktop but can be a slow process to complete the very first time you connect. In testing some power users took upwards of 20 minutes before indexing was complete and the application sluggishness went away. After the initial one-time indexing hit Mail.app should perform fine.

Spamassassin and Controlling Spam

To enable spamassassin filtering:

create a file named .procmailrc in your home directory (~/.procmailrc) containing this line at the top

INCLUDERC=/etc/mail/spamassassin/spamassassin-spamc.rc

Important: The permissions on the .procmailrc file must not permit group writing.

chmod 644 .procmailrc

will allow only read access to group and others on the file. If the file is group writeable sendmail will think the rc file is suspicious and ignore it.

Letting procmail file your spam

Optionally you can add the following three lines below the line above to automatically file messages marked spam in a folder named SPAM in your home directory.

INCLUDERC=/etc/mail/spamassassin/spamassassin-spamc.rc

:0:

* ^X-Spam-Status: Yes

SPAM

Want the SPAM folder someplace else?

* ^X-Spam-Status: Yes

somedirectory/SPAM

Want to tell procmail where your top level home mail directory is?
Place the following at the top of your .procmailrc fileMAILDIR=$HOME/mail

You can use any path you can write to there.
This one says drop things underneath ~/mail (the place most IMAP users will want their message stores).
With MAILDIR set any filing will be done from that default directory.
So with MAILDIR set as above...

* ^X-Spam-Status: Yes

SPAM

would append spam messages to the SPAM file at ~/mail/SPAM

Messages found to be spam will have [SPAM] in the subject line of the message.
You can filter messages with your mail client using this tag.
If you would prefer to not have the subject line changed add the following line to your ~/.spamassassin/user_prefs file

# don't add [SPAM] to subject line which is default rewrite_header Subject

Handling False Positives (messages tagged as SPAM that you would like NOT tagged as SPAM in the future)

There should not be a huge volume of false positives. It is possible though that from time to time a message that you don't percieve as SPAM gets tagged as SPAM by spamassassin because it had certain characteristics. So how can you further personalize your spam tagging?
One of the most effective ways is to white list messages from email addresses that you want to receive mail from.

How To Whitelist Senders That You Don't Want Tagged as SPAMLinux Users

you can whitelist and entire domain using a wildcard like this: whitelist_from *anotheraddress.com

Similarly you can blacklist_from addresses forcing those addresses (or domains) to ALWAYS be tagged as SPAM.

The user_prefs file can be used to give you lots of control over your personal mail spam scanning.
There are other hints inside that file if you choose to explore more expert level personalizations.
For the most part I think most people will find white and black listing sufficient, and the easiest way, to fine tune their personal filtering.

Pruning Back a Large SPAM/Junk Folder (commandline)

If you are filing your Spamassassin Junk mail into a SPAM or Junk folder, and you are not making use of a smart email client to age, and prune back the contents of that folder, you will begin to accumulate a very large Junk folder. If you want to manually manage that folder (which is really just a mbox format file), without just deleting it completely from time to time, you can use this small script to prune the file based on the age of messages inside. /usr/staff/bin/prunemail

This small perl script will inspect a mail file and based on the -n argument, which indicates the number of days back to keep, outputs a new pruned file to STDOUT and a summary report to STDERR.

For instructions on how to run this script and simple examples for redirecting STDERR and STDOUT just type prunemail -h

Absolutely not. All mail will be queued for delivery and sent to the new
server when it is brought online.

What can I do to help with the conversion and minimize downtime?

PLEASE START PURGING and/or MOVING MESSAGES to local folders from your
INBOX (the mail spool). Empty you INBOX if at all possible.
A smaller spool will reduce the mail system downtime on conversion day!

Discuss Post Upgrade Trouble or Ask Questions Here:

email auto-reply vacation program users

The new mailserver does not support the vacation auto reply program. It will be removed soon if it hasn't been already.
The vacation program has some problems and actually hasn't been supported by red hat for some time.
We forced in an old version and made it work because we had a couple of users that still like to use auto reply when away from the office. You could debate whether email is the right medium for truly urgent communication, but those who use the vacation service feel better about acknowledging receipt of their spam and other messages. Anyway I think there are still some vacation users that might
want to still perform autoreplys. You will be able to.

I do have an alternative that will allow vacation users to auto-reply when out of the office. It will be made publicly available very soon.
(probably this week). I will post very simple instructions for using it on the lab pages which are restricted to the internal network rather than post instruciton here. When it is available I will mention it here. In the mean time please avoid using the old vacation program as it will fail.
If you need the service before new instructions are posted early this week just contact me directly and I'll get you set up.

=/var/spool/mail vs. ~/mbox

Pine moves my mail to ~/mbox, but the IMAP server doesn't seem to read this file (I'm using Apple Mail). It does see mail in /var/spool/mail, however, as soon as I use pine, pine moves the mail out of reach.

I usually read mail through a GUI IMAP client but occasionally only have ssh access, which is why I alternate between them.

Pine uses ~/mbox if one exists I think. Usually mbox gets created by running a berkeley mail session. Once ~/mbox exists pine will prefer it. If ~/mbox
does not exist pine will map INBOX to /var/spool/mail.
The old IMAP server (for all it's other troubles) seemed to be able to use /var/spool/mail or mbox if it existed. The new IMAP server cannot do that.

mv ~/mbox underneath your ~/mail directory you can even rename it to something like OLDINBOX or whatever (mv ~/mbox ~/mail/OLDINBOX ). When you do that you will be able to see those messages in a folder called mbox (or OLDINBOX) inside your IMAP client. You can then move those messages back to your spool INBOX if you like or just view them there.

If you run pine again it will find your INBOX on the /var/spool/mail when it sees there is no ~/mbox

BTW if you do use berkeley mail to peek at your messages for some reason exit using x instead of q and the messages will be left on the
spool instead of slurped down to ~/mbox