IT Services

Mail Relays

Title of Service: Mail Relays (Oxmail)

Status of Document: This document describes services offered in June 2011.


1. Introduction

1.1 The University’s mail relay service is provided by a set of servers known collectively as . This system acts in one of two roles:

1.2 Mail Exchanger

A mail exchanger is responsible for receiving the mail destined for a mail domain. DNS MX records describe the exchangers linked to each domain. When oxmail acts as an MX it is normally receiving mail from servers outside Oxford.

1.3 Smarthost

A smarthost delivers mail on behalf of other mail servers. It makes the routing decisions and handles any errors that arise. Oxmail only acts as a smarthost for Oxford mail servers.

1.4 Oxmail aims to provide a reliable mail relay service. No messages are discarded or filtered.

1.5 There are three possible outcomes for each message presented.

1.6 Accept-and-deliver

As much checking as is practical is performed prior to acceptance of a message to maximise the chance of delivery. For mail from outside Oxford, the recipient address is checked with the downstream MTA. The sender address is verified in order to help ensure that in the event of non-delivery after acceptance that an error message can be sent to the sender.

1.7 Accept-retry-and-bounce

Pre-acceptance checking tries to ensure that all accepted messages are deliverable. Any message that cannot be immediately delivered is queued and further delivery attempts are made from time to time. The retry interval starts small and increases with time. A message will be queued for 7 days before being returned to the sender.

1.8 Rejection

Rejection occurs at SMTP time. The sending MTA is responsible for informing the sender of this.

1.9 Messages arriving from outside Oxford are analysed by two methods. All messages are scanned for ‘malware’ by ClamAV software. Any message found to contain malware is rejected after the DATA command. All messages smaller than 150KB are analysed by Spamassassin software to determine a score reflecting the likelihood of the message being ‘spam’. The results of this are recorded in the message headers. Interpretation of this information is left for a downstream process.

2. Summary of OUCS’s responsibilities

Hours of Service

2.1 The service operates at all times.

2.2 Operator cover is provided from 08:30 to 20:30 on weekdays. Periodic monitoring takes place outside these hours, and informal arrangements exist for staff to be called, but no funding is provided to make this contractual.

2.3 If a fault is notified between 09:00 and 17:00 on a working day, OUCS will commence investigation and correction within one hour (provided that no similar fault is also being handled by the same team).

2.4 If a fault is notified outside these hours, OUCS will use its best endeavours to attend the fault, but no funding is allocated to this purpose.

Serviceability Targets

2.5 It is intended, as far as is possible, to maintain service of all components at all times.


2.6 The cluster of machines providing the service is resilient against failure of one or more machines.

2.7 The machines providing the service are distributed between the 129.67 and 163.1 networks.

Alternative Facilities

2.8 No alternative exists to these facilities.

Hardware and Software Maintenance

2.9 The machines used are maintained under warranty by the supplier.

2.10 Software updates are applied by OUCS staff – this is done on a machine-by-machine basis, with no interruption to service.

System Development

2.11 There is no scheduled development time.

Administration and Support

2.12 Information for departmental and college system administrators is given at Information on the malware and spam scanning procedures is given at


2.13 Notification of faults, outages, etc is circulated on the mailing list

Fault Reporting

2.14 Faults should be reported to OUCS Helpdesk. OUCS will liaise with department and College computing officers: no end-user support is provided.

Education and Training

2.15 Not applicable.

3. Summary of client’s responsibilities

3.1 The requirements for University systems to make use of these services are given at

3.2 The client will provide - Contact details of the person with responsibility for departmental and college mail servers, with whom OUCS can liaise over faults, etc.

4. Premium services

4.1 Not applicable.

5. Logging

Logs are kept of mail transactions. This includes RFC5321/RFC5322 message header information. Logs are retained for 90 days.