Background
This note relates to the responsibilities of those who administer a mail domain. These encompass service level expectations of the computer which hosts the Message Transfer Agent and also the expectations of other mail users, both within and outside the domain. Because of these expectations some rules of good practice have been laid down; it is necessary for all to be aware of and to implement these. In addition the relevant Internet standards and best practices should be upheld. Finally, each mail domain places a potential workload on any other mail domain that needs to communicate with it because of the need to liaise when things do not work correctly, and so the University Information Services (UIS) has to restrict the allocation of domains within Cambridge in order to keep the workload on those responsible for mail, including the UIS itself, under control.
For many institutions which have a suitable local computing facility it would appear at first sight that a local mail server would be an effective way of proceeding. This would enable them to exercise appropriate control of their clients, to use the mail system of their choice, and to provide locally things that are difficult for general purpose systems such as those provided by the UIS. However, running a mail server is not a trivial exercise, as the institution will be running a service which is visible from the outside world, and from which the outside world expects certain standards of service. This server is also the primary mail system for its users, all of whom will also require a certain standard of service.
Managed mail domains
For institutions that wish to run a college, department or group mail domain, but do not want the responsibility of running the underlying computer system, University Information Services provides a managed domain facility which implements mail domains on UIS systems, defined by lists managed by the institution. The institution will still need to observe the requirements specified below, with the obvious exception of those which refer to the details of the management of a computer system.
For more information on this facility see Managed Mail Domains
National and international regulations
Applicability
A reasonable attempt should be made to ensure that all users that come under the administration which the name represents are registered in the domain's mail system. The reason for this is to make it likely that those attempting to send mail to people in the institution will find the intended recipient there. For example, if a department within Cambridge called colloid sets up a mail domain colloid.cam.ac.uk, then all those within colloid, and all those who might reasonably be expected to be available via colloid, should be offered a mail address on that mail domain. This might be of the form fred@colloid.cam.ac.uk though the actual allocation of domain-names is subject to negotiation.
These users do not all have to read their mail at colloid. The domain should support user-specified forwarding so that users with multiple mailboxes, for example in their college and one or more departments, can forward their mail to their preferred mailbox
If the domain concerned is a college, then a reasonable attempt is interpreted as follows: all permanent staff of the college should be able to have mail addressed to them at the college, but it is not necessary to register any students. So far as the registration of the permanent staff is concerned it is sufficient to provide a fixed forwarding to a standard Cambridge mail address, for example crsid@cam.
Availability
The mail host system must have no planned downtime longer than a day except by special prior arrangement with the University Information Services, who should also be contacted in the case of unexpected downtime likely to last longer than one day.
Systems which deliver mail expect to be able to move incoming mail off their queues quickly, and many do not have a large amount of space in which to store messages which cannot be delivered because the receiving mail machine is not running. They protect themselves against becoming full by having a relatively short timeout, after which the incoming mail is returned to sender as undeliverable. This timeout may be as short as one day. Mail returned as undeliverable for this reason is seen by the sender of the mail as unfriendly, whereas if the mail host system remains running then it will store the mail until the recipient returns, which is more user-friendly.
In view of these considerations, special arrangements for exceptionally long downtime can only be made if it is clear that there will be enough space to store the potential incoming mail.
Standard mailboxes
In the event of a problem with incoming or outgoing mail from a mail domain, those who try to resolve such problems (which may be the user, or someone responsible for other mail domains) will expect to be able to communicate with a special mail ID POSTMASTER. It is a requirement that there shall be a POSTMASTER mailbox in each domain, and that suitable arrangements shall be made for this mailbox to be regularly and frequently serviced, and responded to with a reasonable turnround.
Mailbox names should also be provided for other common services, roles and functions, for example abuse@domain, webmaster@domain, in accordance with RFC 2142 - Mailbox Names for Common Services, Roles and Functions.
Address validity
All addresses in header fields that specify the originator of a message, such as From:, Sender: and Reply-To:, must be valid email addresses; that is the specified domain name must be a valid email domain, and the specified userid must be a valid user of electronic mail on that domain.
Loop protection
To protect against mail going around the networks indefinitely, the mail program installed needs to have a loop detector. This is usually implemented by forbidding 'too many hops'; that is, too many intervening mail systems between the sender and the receiver. If this number is set to a large number (25 may suffice), then the program is likely to catch all genuine loops, and not to be falsely triggered by complicated routings.
Registration
The mail domain must be registered in the DNS. Computer Officers in departments and Colleges are able to manage their own IP address space.
For further information about the DNS and registration see the page on obtaining IP addresses, although note that some of this material has been superseded by the facility for managing IP address space noted in the paragraph above.
While a simple A record in the DNS is sufficient to receive electronic mail, current Internet rules recommend an MX record, and the UIS requires this for email systems in Cambridge.
Cambridge requirements
Point of contact
There must be a single point of contact responsible for the mail domain, who can be contacted by UIS when necessary; this will usually be the person who responds to mail to POSTMASTER (see standard mailboxes above), together with whatever arrangements are made for deputies in case of absence.
DNS registration
All mail domains must have an MX record in the DNS. For domains under cam.ac.uk, we require that the mail domain name is not that of a physical machine, but instead the MX record is used to point to a physical machine. (This is enforced by the central mail relay.) In this way, when the host machine of a domain is altered, only the MX record needs to be changed, and existing email addresses will continue to work.
Mail domains can also have SPF, DKIM, and DMARC authentication records in the DNS. There is another page with more information about how we manage DNS for email.
Institution-wide
The UIS will normally allow only one email domain per institution. The reason for this is to keep the potential explosion of mail domains and their management to a size that can be coped with by the UIS (and anyone else who may have to deal with them), so that, for example, they will only need to deal with up to about 100 postmasters, rather than several thousand.
If an institution does have smaller subdomains covering parts of the institution, the UIS will normally only interface with the management of the mail domain that covers the institution (department, college, or the equivalent) as a whole. A mail domain within an institution must interface to the UIS entirely through appropriate official channels of the institution to which it belongs; this will usually be through an institution's computer officer(s). In particular, requests to hostmaster to set up MX record(s) in the DNS must be made through this official channel, so that the persons responsible know what is happening within their sub-network.
Where there are subdomains within an institution, and the mail for these subdomains is routed via the host system for the institutional mail domain, then the availability rule (Availability above) can be relaxed with the consent of the local postmaster. For example, the local host may implement a message store, and be prepared to hold mail indefinitely.
Off-site mail service providers
There is an exception to the preference for a single Institution Wide mail domain. Where an institution uses off-site mail service providers, the institution can request provider-specific subdomains. Common examples are bulk mail / mailshot services, or web-based services that are not primarily mail services but which need to send transactional messages.
Separating out a third-party mail service onto its own domain has a couple of advantages.
It is necessary to publish mail authentication records (SPF and DKIM) in the DNS to reduce problems with mis-classifying legitimate mail as spam; these DNS records are easier to manage if separate mail services have separate mail domains.
If a mail provider needs to receive email at multiple email addresses, this can be easier to manage if you do not have to set up the addresses both in your institution's main mail domain as well as at the off-site provider.
Mail on systems that are intermittently available
For reasons indicated above, we will not register mail domains on machines that are not in principle available almost all the time. Thus domains based on hosts that are switched off for the whole of a vacation, or which are only connected to the network intermittently, are very unlikely to be authorised.
Smarthosts
The mail domain must use a suitable system as a smarthost to relay outgoing email unless other arrangements have been agreed. This is enforced by packet filters in the CUDN. In most cases the central mail switch run by the UIS (ppsw.cam.ac.uk) is the right smarthost to use.
In addition institutions are encouraged to receive incoming mail through mx.cam.ac.uk. This will enable the institution to take advantage of the anti-virus and spam scoring provided by that system. For further information on these see the pages on the central email scanner.
Firewalls
Institutions that run their own mail servers and which receive incoming email via mx.cam.ac.uk must configure any firewalls or packet filters to allow SMTP connections from any address in 131.111.8.128/27 (and 2001:630:212:8::e:0/112 if you use IPv6). These address ranges are dedicated to the central email relay. We may change the set of IP addresses in active use within this range at any time. Please do not configure your firewall using host names since this causes problems when the DNS changes.
For outgoing email, you should configure your firewall to allow connections to 131.111.8.128/27 (and 2001:630:212:8::e:0/112 if you use IPv6)) on port 25. This includes ppsw.cam.ac.uk and smtp.hermes.cam.ac.uk and you should allow connections to anywhere on ports 110, 143, 465, 587, 993, 995 which are used by roaming MUAs.
Address verification
Collateral spam is caused by email systems that accept messages before verifying that they are deliverable, and therefore send bounce messages in response to spam. In order to minimise the amount of collateral spam originating from Cambridge, email systems in the University must validate local recipient addresses at SMTP time, before accepting messages from the public Internet. Address verification also reduces our email systems' vulnerability to dictionary attacks - when spammers send large numbers of messages to made-up email addresses hoping some of them might be deliverable.
Further information
If you have technical questions about running a mail domain contact postmaster@uis.cam.ac.uk
Last checked: March 2017