Sun Microsystems Sun Workstation 100U System Manager's Manual page 317

SENDMAIL
system administrator, as weD as domain-based addressing. It helps guide the conversion of me&-
sage formats between disparate networks. In short, Bendmoil is designed to assist a graceful tran-
sition to consistent internetwork addressing schemes.
Section 1 discusses the design goals for Ben4moil. Section 2 gives an overview of the basic
functions of the system. In section 3, details of usage are discussed. Section 4 compares 8endmoil
to other internet mail routers, and an evaluation of 8en4moil is given in section 5, including ruture
plans.
1. DESIGN GOALS
(1)
(2)
(3)
(4)
(5)
Design goals Cor 8en4moil include:
Compatibility with the existing mail programs, including Bell version 6 mail, Bell ver-
sion 7 mail [UNIX83J, Berkeley Moil (Shoens79J, BerkNet mail (Schmidt79J, and hope-
fully UUCP mail [Nowitz78a, Nowitz78bJ. ARPANET mail [Crocker77a, P08teI77) was
also required.
Reliability, in the sense of guaranteeing that every message is correctly delivered or at
least brought to the attention of a human for correct disposal; no message should ever
be
completely lost. This goal was considered essential because of the emphasis on mail in
our environment. It has turned out to
be
one of the hardest goals to satisfy, especially
in the face oC the many anomalous message formats produced by various ARPANET
sites. For example, certain sites generate improperly formated addresses, occasionally
causing error-message loops. Some hosts use blanks in names, causing problems with
UNIX mail programs that assume that an address
is
one word. The semantics of some
fields are interpreted slightly differently by different sites. In summary, the obscure
features of the ARPANET mail protocol really ore used and are difficult to support, but
must be supported.
Existing sortware to do actual delivery should
be
used whenever possible. This goal
derives as much rrom political and practical considerations as technical.
Easy expansion to fairly complex environments, including multiple connections to a sin-
gle network type (such as with multiple UUCP or Ether nets [MetcalCe76)). This goal
requires consideration of the contents oC an addre88 as well as its syntax in order to
determine which gateway to use. For example, the ARPANET is bringing up the TCP
protocol to replace the old NCP protocol. No host at Berkeley runs both TCP and
NCP, so it is necessary to look at the ARPANET host name to determine whether to
route mail to an NCP gateway or a TCP gateway.
Configuration should not be compiled into the code. A single compiled program should
be able to run as is at any site (barring such basic changes as the CPU type or the
operating system). We have found this seemingly unimportant goal to be critical in real
lire. Besides the simple problems that occur when any program gets recompiled in a
different environment, many sites like to "fiddle" with anything that they will
be
recom-
piling anyway.
(6) Sendmail must
be
able to let various groups maintain their own mailing lists, and let
individuals speciCy their own Corwarding, without modiCying the system alias file.
(7) Each user should be able
to
speciry which mailer to execute to process mail beinl
delivered Cor him. This feature allows users who are using specialized mailers that use a
different rormat to build their environment without changing the system, and facilitates
specialized Cunctions (such as returning an "I am on vacation" message).
(8) Network traffic should be minimized by batching addresses to a single host where possi-
ble, without assistance Crom the user.
These goals motivated the architecture illustrated in Figure 1. The user interacts with a
mail generating and sending program. When the mail is created, the generator calls 8endmoil,
Version 4.1 DRAFT
Last Mod 8/"'/83