University policy and procedures for handling SPAM email

University policy and procedures for handling SPAM email

Abstract

Spam is unsolicited, or "junk", email that is analogous to unwanted circulars that are received in paper mail. However spam does not only encompass unwanted advertising material, but may include pornographic material which the recipient may find extremely offensive. The University has a clear duty of care to protect its employees from this type of harassment. In addition to any personal distress caused, spam places an unnecessary burden on University ICT systems in terms of processing and storage. This policy is aimed at minimising the amount of spam reaching recipients within the University.

Why is it important?

E-mail is a key tool for asynchronous communication with colleagues both within the University and worldwide. University email systems deal with in excess of 100,000 messages on a daily basis. However the usefulness of email is being undermined by the large volume of spam messages that are received. The results of a pilot within Computing Service revealed that some 35% of all incoming email is spam. There is a danger that important email messages will be missed through being lost in the deluge of spam.

The processing of such messages and the storage and backup of the email files is a waste of resources. Equally importantly, every email user in the University spends time needlessly having to deal with a high, and increasing, volume of unwanted mail.

Key issues

A considerable amount of spam originates from well known networks or specific sites on the Internet. Spam from these sites can be automatically blocked by subscribing to the Realtime Blackhole List (RBL) service that is funded by UKERNA on behalf of the JANET community. For some time now the Computing Service has been using this blacklist facility and rejecting circa 80,000 messages a week with a message to the originator.

An increasing volume of spam does not originate from a blacklisted site. To deal with such messages, it is necessary to filter on the content of the message rather than the IP address of the originating mail system. Content filtering, which is a completely automatic process using specially designed software, is a considerably more complex process. It operates by 'scoring' a message according to certain inherent characteristics. The higher the score, the more certain the message is spam. Where a threshold is reached, the email can be rejected, with an error message going to the sender.

However the software is not infallible. It is possible that legitimate email of a commercial advertising nature is erroneously identified as spam. Thus it is desirable to provide a mechanism (for users who so wish) to receive all such emails. In this case, where the score threshold is reached, the email can have the subject line tagged with [SPAM] before being passed on to the recipient who can then take the final decision on whether the content actually is spam.

The threshold for rejecting or tagging mail should be set based on experience and reviewed on a regular basis to meet the evolving composition of incoming email.

Who has the responsibility?

The Computing Service has responsibility for the management and operation of the mailhubs that handle incoming email from JANET and the wider Internet. For maximum effectiveness and efficiency mail should be filtered on the mailhubs at the interface to the JANET network. Where a Faculty or department has decided to run its own mail server bypassing the mailhub, the decision on filtering should be taken locally and all such systems registered with Computing Service.

What is the procedure?

  1. The central University mailhubs should be the normal platform for handling all incoming mail and implementing University policy on dealing with spam.
  2. The Computing Service should subscribe to Internet blacklist services that are aimed at reducing spam e.g. the RBL service endorsed by UKERNA.
  3. The Computing Service should implement automatic content filtering software e.g. Spam Assassin to minimise spam.
  4. By default, messages identified as spam should be automatically rejected with a message to the originator.
  5. The Computing Service should provide a self-service web page where anyone can opt for such messages to be tagged [SPAM] and delivered rather than rejected.
  6. The operational parameters that are used to reject and tag messages should be regularly reviewed by Computing Service and modified to meet changing circumstances.
  7. The Computing Service should maintain a local blacklist of sources from where spam is being received and deal with this as in a) above.

Prepared by: A.Scrimgeour

Created by: Linda McCormick

Created on: 6 May 2003; last modified on: 6 May 2003; published on: 6 May 2003