MTURFC-0001 October 19, 1994 A Standard For E-Mail Implementation at Michigan Technological University This RFC is an official specification for the MTU community. The first section provides background information while the second section specifies implementation details. Distribution of this document is unlimited. E-mail is mission critical at this university and therefore requires a robust implementation. Four main issues were considered during the drafting of this specification. These issues, listed in order of increasing importance, are as follows: 1) More than one machine receives e-mail. There are currently over 15000 userids which are able to receive e-mail at this university. There are over 2000 different machines that these people can use to read their mail. This is too much of a load for one machine to handle efficiently, thus some departments have elected to spool their own e-mail on their own servers. Since more than one machine receives e-mail, a mechanism must be in place to allow messages to reach these machines. There are two possibilities: a) messages are sent directly to the destination machine b) messages are sent to a central machine which forwards them to the destination machine 2) E-mail addresses should remain constant. People move around all the time, especially the students. Sometimes they want their mail sent to them in the CS department, sometimes they want it in the EE department. These changes should be transparent to the other users. It is unreasonable to require that people consult a campus directory every time they want to send a message. By making all e-mail go through a central machine which then redistributes the messages to the appropriate client machines, all users appear to have a static e-mail address even though their behind-the-scenes address is dynamic. 3) E-mail addresses should never be ambiguous. All messages addressed to "eric" should be delivered to the same mailbox regardless of where the message originated. This statement has substantial implications. If the e-mail address does not specify a hostname, the default behavior of the mail software (i.e. "sendmail") is to assume the message is intended for the local machine. This assumption is certainly not correct for this environment since it requires that every machine on the campus maintain a mailbox for every user on the campus. It is also not correct to assume that the message should be forwarded to the local e-mail server, since "eric" would imply "eric@cs.mtu.edu" in the CS department and "eric@phy.mtu.edu" in the physics department. This ambiguity is undesirable and should be avoided. The only solution is to insure that "eric" implies "eric@some.constant.hostname" everywhere on the campus. 4) E-mail should be easy to use. First, knowledge of which department an individual belongs to should not be required in order to send that person e-mail. It is confusing to have to know that Mary belongs to the CS department so her address is "mary@cs.mtu.edu" but Joe is in the EE department so his address is "joe@ee.mtu.edu." Users will be less confused if they don't have to type a hostname to send a message locally. For people at other sites wanting to send e-mail to people at this university, the address "userid@mtu.edu" should always be sufficient. Second, when people want all their incoming mail forwarded to another location temporarily (if they are away at a conference, for example) or even permanently, they should not have to maintain a ".forward" file everywhere they have an account. Instead, there should be one central location where each person can register a forwarding address. All incoming mail for these people would then be redirected to these addresses. Conclusion: There is only one solution which satisfies the above requirements. All e-mail for the campus must be sent to a central mailer (e.g. mtu.edu) where it can then be forwarded to the appropriate place. Replies to messages must also be sent to the central mailer, which means the message headers in outgoing mail must be rewritten to give the appearance that it originated on the central mailer. This will provide an unambiguous e-mail environment, making e-mail easy for people to use and understand. The remainder of this document specifies the requirements of each department for implementing this defined standard. Definition of Terms: Alias: user1 => user2[@host] Special Alias: special-user (e.g. root, daemon, etc.) => user[@host] Local Alias: Alias expanded by departmental relay or mailer machines Forward: Pipe or short-term alias Deliver: Write messages to mailbox or pipe (final destination of message) Relay: Send messages to another machine for processing Mailer: Delivers local mail and relays non-local mail Gateway: Allows non-TCP/IP networks to transfer e-mail to and from TCP/IP networks Possible Forms of E-Mail Addresses: user user@mtu.edu user@some.host.mtu.edu user@some.other.host General Requirements: Addresses in the first two forms above MUST be equivalent. That is, messages addressed to "user" MUST be delivered to the same final destination as messages addressed to "user@mtu.edu." Note that this also includes messages where "user" is the name of a mailing list. Exception: messages addressed to special-users should be treated differently (see "Alias Requirements:" below). Message headers must be rewritten such that return addresses look like "user@mtu.edu" instead of "user@some.host.mtu.edu." The central campus mailer (mtu.edu) MUST have a backup mailer to handle e-mail in case of failure. Non TCP/IP networks that support e-mail MUST have a gateway that allows e-mail to be sent to or from the campus TCP/IP network according to this specification. Discussion: If unqualified e-mail addresses (those that do not specify a hostname) are to work the same regardless of where messages originate, a hostname constant across campus must be implied. This hostname will be "mtu.edu" which is the name of the central mailer. All messages originating anywhere on this campus should have return addresses pointing at the central mailer, except those messages sent from a "special" user (i.e. "root"). Since these special accounts are used for administrative purposes all over the campus, mail sent from these accounts should have replies directed back to the administrator of that particular domain. These special accounts are the only accounts allowed to send messages with return addresses pointing back to the domain where the messages originate. See "Alias Requirements:" below for more details. Departmental Requirements: All departments MUST have a competent system administrator responsible for their department's e-mail. All departments MUST maintain one or more RFC1123 compliant SMTP relay machines. All e-mail originating in a department MUST be collected by a relay machine in that department before being forwarded to the central mailer. A department MAY spool its own local mail. This is encouraged but not required at this time. Discussion: Only client machines capable of processing DNS MX (mail exchanger) records can take advantage of the central mailer's backup machine. Many e-mail user agents are incapable of processing MX records. Because of this, all departments are required to maintain at least one machine to act as a relay (or "mail hub"), collecting messages from the various client machines in their departments and forwarding these messages to the central mailer. RFC1123 requires that such a mailer recognize and use MX records. It is strongly recommended that a department only have one or two relay machines in each general area (e.g. a lab of client machines) in order to lessen the number of SMTP connections to the central mailer. Alias Requirements: The backup mailer MUST maintain and use a current copy of the core set of campus aliases (i.e. user aliases, not necessarily mailing lists). It SHOULD maintain and use a copy of all the aliases, including mailing lists. All relay machines MUST support special aliases. Messages addressed to special-users SHOULD be spooled locally on a relay machine but they MAY be forwarded to the appropriate system administrator instead. These messages MUST NOT be forwarded to the central campus mailer unless they are specifically addressed to do so. A department's relay machine MAY use a copy of the master alias file to resolve unqualified addresses (those that do not specify a hostname) instead of sending them to the central mailer. This mechanism used to maintain this secondary copy of the alias file is beyond the scope of this document, however it is subject to the following constraints: The relay machine MUST attempt to refresh its secondary copy of the alias file at least once every 10 minutes. Secondary copies of the alias file older than 24 hours MUST NOT be used to resolve addresses under any circumstances. All messages addressed to people not found in the secondary copy of the alias file MUST be forwarded to the central campus mailer for processing. Discussion: If the backup mailer is to be useful, it must be able to deliver messages while the central mailer is unavailable. Obviously the backup mailer cannot deliver messages to the central mailer's spool area, but it should have the ability to deliver all other messages. This can be accomplished if it has access to the same alias information that the central mailer uses. Due to the dynamic nature of alias information, mailing lists, mail filters, etc. that the central mailer uses, it may be difficult for the backup mailer to maintain a complete and accurate copy of this information. An acceptable compromise is to require the backup mailer to maintain at least the user aliases. The backup mailer need not maintain aliases for mailing lists, however this would be preferable. Since every department uses special administrative accounts, there must be some mechanism for these accounts to send and receive mail without conflicting with other departments. Special aliases provide this mechanism. Messages addressed to "root" for example should be delivered to root's mailbox in that domain instead of being forwarded to the central mailer. Messages sent from "root" should have a return address of "root@domain.mtu.edu." This distinction allows administrators to send and receive mail using administrative accounts. For departments that find it unacceptable for local messages to be forwarded to the central mailer and back again to the department's relay machine, an alternate configuration is allowed. The department's relay machine may use a copy of the alias information in lieu of sending messages to the central mailer for processing. Maintaining consistency among such configurations is a non- trivial task, thus there are strict requirements that the relay machine must obey. The goal is to duplicate exactly the processing that would normally be done by the central mailer, with no side effects. When in doubt, the central mailer is the only authority.