Because of repeated problems with unsecured departmental computers being used as "junk mail relays", We have reluctantly introduced measures which restrict access to mail "listeners" running on computers on the local network, from systems outside of the local network.
These measures are not expected to impact adversely on the vast majority of members of the University, who send and receive mail through the University of Bristol Information Services maintained and/ or supported mail systems. Those most likely to be affected are the keen enthusiasts, who have connected computers to the local network, which are capable of running network services and who have not sought advice on how best to configure the services running on them (be they Linux - or other UNIX based workstations - NT servers, Apple Macintoshes or anything else). If our recommendations are followed, then there should, in general, be no need whatsoever for any local machine to be exposed to the rest of the Internet for mail purposes.
If however, there is a need to be so exposed, then we can selectively open up access on a host by host basis. Before we will do this, though, certain conditions must be met.
the local system must be configured such that it can not be used as a mail relay from anywhere outside of the local network. This means that if the system concerned is given a message by any system not on the local network and is asked to pass the message on to any other system not on the local network, then it must refuse to do so.
the system must be using mail software which correctly logs the identity of systems connecting to it (either the correct DNS name, or else the IP address, or both). When a system connects to another for a mail exchange, it is supposed to identify itself in the initial "HELO/EHLO" greeting with its correct hostname. Some mail software is sufficiently naive to take this at face value and not check what the system really is. The software running on any system seeking approval for exposure to the rest of the Internet must log the correct DNS name, IP address or both. The information must be included in a "Received:" header inserted by the mail software.
the system must have an identifiable, responsible administrator who is registered on the local mail administrators mailing list. The administrator must ensure that the system is kept secure.
the system must keep accurate time and log mail transactions (at some level), time stamping the logged messages. Transaction logs must be kept for a minimum of 4 weeks.
at the request of the Assistant Director (Information Systems & Computing), full administrative access to the system must be granted to Information Services staff, on demand.
the system must support a "postmaster" mailbox, which must be serviced on a regular basis.
these conformance requirements are subject to change. If they ever do, then we shall endeavour to give you due notice, but any new conformance requirements must be met in a timely fashion.
Information Services reserves the right to disapprove approved systems at any time, without notice. We would not do this lightly.
a limited number of systems per department will be permitted to be exposed. Other systems which might otherwise need exposing will be addressed by the use of MX records in the DNS, pointing at one or more of the already exposed systems.
the system must not be configured to use any other University system as a default mail relay/ gateway, unless the other system is itself an exposed system (and subject to the permission of its administrator).
As implied earlier, filtering will only take place on packets coming into the local network from the external network; there will be no filtering of packets originating locally. Other things being equal, this could mean that some local systems would be able to send, but not be able to receive mail. As an alternative to "exposure" to the Internet, it is possible (and preferred) to configure things centrally such that incoming mail for such systems is routed transparently via the central mail hubs.