1.nr si 3n
2.he 'Mail Systems and Addressing in 4.2bsd''%'
3.fo 'Version 8.1'USENIX \- Jan 83'Last Mod 06/07/93'
4.if n .ls 2
5.+c
6.(l C
7.sz 14
8Mail Systems and Addressing
9in 4.2bsd
10.sz
11.sp
12Eric Allman\(dg
13.sp 0.5
14.i
15Britton-Lee, Inc.
161919 Addison Street, Suite 105.
17Berkeley, California 94704.
18.sp 0.5
19.r
20eric@Berkeley.ARPA
21ucbvax!eric
22.)l
23.sp
24.(l F
25.ce
26ABSTRACT
27.sp \n(psu
28Routing mail through a heterogeneous internet presents many new
29problems.
30Among the worst of these is that of address mapping.
31Historically, this has been handled on an ad hoc basis.
32However,
33this approach has become unmanageable as internets grow.
34.sp \n(psu
35Sendmail acts a unified
36.q "post office"
37to which all mail can be
38submitted.
39Address interpretation is controlled by a production
40system,
41which can parse both old and new format addresses.
42The
43new format is
44.q "domain-based,"
45a flexible technique that can
46handle many common situations.
47Sendmail is not intended to perform
48user interface functions.
49.sp \n(psu
50Sendmail will replace delivermail in the Berkeley 4.2 distribution.
51Several major hosts are now or will soon be running sendmail.
52This change will affect any users that route mail through a sendmail
53gateway.
54The changes that will be user visible are emphasized.
55.)l
56.sp 2
57.(f
58\(dgA considerable part of this work
59was done while under the employ
60of the INGRES Project
61at the University of California at Berkeley.
62.)f
63.pp
64The mail system to appear in 4.2bsd
65will contain a number of changes.
66Most of these changes are based on the replacement of
67.i delivermail
68with a new module called
69.i sendmail.
70.i Sendmail
71implements a general internetwork mail routing facility,
72featuring aliasing and forwarding,
73automatic routing to network gateways,
74and flexible configuration.
75Of key interest to the mail system user
76will be the changes in the network addressing structure.
77.pp
78In a simple network,
79each node has an address,
80and resources can be identified
81with a host-resource pair;
82in particular,
83the mail system can refer to users
84using a host-username pair.
85Host names and numbers have to be administered by a central authority,
86but usernames can be assigned locally to each host.
87.pp
88In an internet,
89multiple networks with different characteristics
90and managements
91must communicate.
92In particular,
93the syntax and semantics of resource identification change.
94Certain special cases can be handled trivially
95by
96.i "ad hoc"
97techniques,
98such as
99providing network names that appear local to hosts
100on other networks,
101as with the Ethernet at Xerox PARC.
102However, the general case is extremely complex.
103For example,
104some networks require that the route the message takes
105be explicitly specified by the sender,
106simplifying the database update problem
107since only adjacent hosts must be entered
108into the system tables,
109while others use logical addressing,
110where the sender specifies the location of the recipient
111but not how to get there.
112Some networks use a left-associative syntax
113and others use a right-associative syntax,
114causing ambiguity in mixed addresses.
115.pp
116Internet standards seek to eliminate these problems.
117Initially, these proposed expanding the address pairs
118to address triples,
119consisting of
120{network, host, username}
121triples.
122Network numbers must be universally agreed upon,
123and hosts can be assigned locally
124on each network.
125The user-level presentation was changed
126to address domains,
127comprised of a local resource identification
128and a hierarchical domain specification
129with a common static root.
130The domain technique
131separates the issue of physical versus logical addressing.
132For example,
133an address of the form
134.q "eric@a.cc.berkeley.arpa"
135describes the logical
136organization of the address space
137(user
138.q eric
139on host
140.q a
141in the Computer Center
142at Berkeley)
143but not the physical networks used
144(for example, this could go over different networks
145depending on whether
146.q a
147were on an ethernet
148or a store-and-forward network).
149.pp
150.i Sendmail
151is intended to help bridge the gap
152between the totally
153.i "ad hoc"
154world
155of networks that know nothing of each other
156and the clean, tightly-coupled world
157of unique network numbers.
158It can accept old arbitrary address syntaxes,
159resolving ambiguities using heuristics
160specified by the system administrator,
161as well as domain-based addressing.
162It helps guide the conversion of message formats
163between disparate networks.
164In short,
165.i sendmail
166is designed to assist a graceful transition
167to consistent internetwork addressing schemes.
168.sp
169.pp
170Section 1 defines some of the terms
171frequently left fuzzy
172when working in mail systems.
173Section 2 discusses the design goals for
174.i sendmail .
175In section 3,
176the new address formats
177and basic features of
178.i sendmail
179are described.
180Section 4 discusses some of the special problems
181of the UUCP network.
182The differences between
183.i sendmail
184and
185.i delivermail
186are presented in section 5.
187.sp
188.(l F
189.b DISCLAIMER:
190A number of examples
191in this paper
192use names of actual people
193and organizations.
194This is not intended
195to imply a commitment
196or even an intellectual agreement
197on the part of these people or organizations.
198In particular,
199Bell Telephone Laboratories (BTL),
200Digital Equipment Corporation (DEC),
201Lawrence Berkeley Laboratories (LBL),
202Britton-Lee Incorporated (BLI),
203and the University of California at Berkeley
204are not committed to any of these proposals at this time.
205Much of this paper
206represents no more than
207the personal opinions of the author.
208.)l
209.sh 1 "DEFINITIONS"
210.pp
211There are four basic concepts
212that must be clearly distinguished
213when dealing with mail systems:
214the user (or the user's agent),
215the user's identification,
216the user's address,
217and the route.
218These are distinguished primarily by their position independence.
219.sh 2 "User and Identification"
220.pp
221The user is the being
222(a person or program)
223that is creating or receiving a message.
224An
225.i agent
226is an entity operating on behalf of the user \*-
227such as a secretary who handles my mail.
228or a program that automatically returns a
229message such as
230.q "I am at the UNICOM conference."
231.pp
232The identification is the tag
233that goes along with the particular user.
234This tag is completely independent of location.
235For example,
236my identification is the string
237.q "Eric Allman,"
238and this identification does not change
239whether I am located at U.C. Berkeley,
240at Britton-Lee,
241or at a scientific institute in Austria.
242.pp
243Since the identification is frequently ambiguous
244(e.g., there are two
245.q "Robert Henry" s
246at Berkeley)
247it is common to add other disambiguating information
248that is not strictly part of the identification
249(e.g.,
250Robert
251.q "Code Generator"
252Henry
253versus
254Robert
255.q "System Administrator"
256Henry).
257.sh 2 "Address"
258.pp
259The address specifies a location.
260As I move around,
261my address changes.
262For example,
263my address might change from
264.q eric@Berkeley.ARPA
265to
266.q eric@bli.UUCP
267or
268.q allman@IIASA.Austria
269depending on my current affiliation.
270.pp
271However,
272an address is independent of the location of anyone else.
273That is,
274my address remains the same to everyone who might be sending me mail.
275For example,
276a person at MIT and a person at USC
277could both send to
278.q eric@Berkeley.ARPA
279and have it arrive to the same mailbox.
280.pp
281Ideally a
282.q "white pages"
283service would be provided to map user identifications
284into addresses
285(for example, see
286[Solomon81]).
287Currently this is handled by passing around
288scraps of paper
289or by calling people on the telephone
290to find out their address.
291.sh 2 "Route"
292.pp
293While an address specifies
294.i where
295to find a mailbox,
296a route specifies
297.i how
298to find the mailbox.
299Specifically,
300it specifies a path
301from sender to receiver.
302As such, the route is potentially different
303for every pair of people in the electronic universe.
304.pp
305Normally the route is hidden from the user
306by the software.
307However,
308some networks put the burden of determining the route
309onto the sender.
310Although this simplifies the software,
311it also greatly impairs the usability
312for most users.
313The UUCP network is an example of such a network.
314.sh 1 "DESIGN GOALS"
315.pp
316Design goals for
317.i sendmail \**
318.(f
319\**This section makes no distinction between
320.i delivermail
321and
322.i sendmail.
323.)f
324include:
325.np
326Compatibility with the existing mail programs,
327including Bell version 6 mail,
328Bell version 7 mail,
329Berkeley
330.i Mail
331[Shoens79],
332BerkNet mail
333[Schmidt79],
334and hopefully UUCP mail
335[Nowitz78].
336ARPANET mail
337[Crocker82]
338was also required.
339.np
340Reliability, in the sense of guaranteeing
341that every message is correctly delivered
342or at least brought to the attention of a human
343for correct disposal;
344no message should ever be completely lost.
345This goal was considered essential
346because of the emphasis on mail in our environment.
347It has turned out to be one of the hardest goals to satisfy,
348especially in the face of the many anomalous message formats
349produced by various ARPANET sites.
350For example,
351certain sites generate improperly formated addresses,
352occasionally
353causing error-message loops.
354Some hosts use blanks in names,
355causing problems with
356mail programs that assume that an address
357is one word.
358The semantics of some fields
359are interpreted slightly differently
360by different sites.
361In summary,
362the obscure features of the ARPANET mail protocol
363really
364.i are
365used and
366are difficult to support,
367but must be supported.
368.np
369Existing software to do actual delivery
370should be used whenever possible.
371This goal derives as much from political and practical considerations
372as technical.
373.np
374Easy expansion to
375fairly complex environments,
376including multiple
377connections to a single network type
378(such as with multiple UUCP or Ethernets).
379This goal requires consideration of the contents of an address
380as well as its syntax
381in order to determine which gateway to use.
382.np
383Configuration information should not be compiled into the code.
384A single compiled program should be able to run as is at any site
385(barring such basic changes as the CPU type or the operating system).
386We have found this seemingly unimportant goal
387to be critical in real life.
388Besides the simple problems that occur when any program gets recompiled
389in a different environment,
390many sites like to
391.q fiddle
392with anything that they will be recompiling anyway.
393.np
394.i Sendmail
395must be able to let various groups maintain their own mailing lists,
396and let individuals specify their own forwarding,
397without modifying the system alias file.
398.np
399Each user should be able to specify which mailer to execute
400to process mail being delivered for him.
401This feature allows users who are using specialized mailers
402that use a different format to build their environment
403without changing the system,
404and facilitates specialized functions
405(such as returning an
406.q "I am on vacation"
407message).
408.np
409Network traffic should be minimized
410by batching addresses to a single host where possible,
411without assistance from the user.
412.pp
413These goals motivated the architecture illustrated in figure 1.
414.(z
415.hl
416.ie t \
417.	sp 18
418.el \{\
419.(c
420+---------+   +---------+   +---------+
421| sender1 |   | sender2 |   | sender3 |
422+---------+   +---------+   +---------+
423     |  	   |             |
424     +----------+  +  +----------+
425		|  |  |
426		v  v  v
427            +-------------+
428            |   sendmail  |
429            +-------------+
430		|  |  |
431     +----------+  +  +----------+
432     |  	   |             |
433     v             v             v
434+---------+   +---------+   +---------+
435| mailer1 |   | mailer2 |   | mailer3 |
436+---------+   +---------+   +---------+
437.)c
438.\}
439
440.ce
441Figure 1 \*- Sendmail System Structure.
442.hl
443.)z
444The user interacts with a mail generating and sending program.
445When the mail is created,
446the generator calls
447.i sendmail ,
448which routes the message to the correct mailer(s).
449Since some of the senders may be network servers
450and some of the mailers may be network clients,
451.i sendmail
452may be used as an internet mail gateway.
453.sh 1 "USAGE"
454.sh 2 "Address Formats"
455.pp
456Arguments may be flags or addresses.
457Flags set various processing options.
458Following flag arguments,
459address arguments may be given.
460Addresses follow the syntax in RFC822
461[Crocker82]
462for ARPANET
463address formats.
464In brief, the format is:
465.np
466Anything in parentheses is thrown away
467(as a comment).
468.np
469Anything in angle brackets (\c
470.q "<\|>" )
471is preferred
472over anything else.
473This rule implements the ARPANET standard that addresses of the form
474.(b
475user name <machine-address>
476.)b
477will send to the electronic
478.q machine-address
479rather than the human
480.q "user name."
481.np
482Double quotes
483(\ "\ )
484quote phrases;
485backslashes quote characters.
486Backslashes are more powerful
487in that they will cause otherwise equivalent phrases
488to compare differently \*- for example,
489.i user
490and
491.i
492"user"
493.r
494are equivalent,
495but
496.i \euser
497is different from either of them.
498This might be used
499to avoid normal aliasing
500or duplicate suppression algorithms.
501.pp
502Parentheses, angle brackets, and double quotes
503must be properly balanced and nested.
504The rewriting rules control remaining parsing\**.
505.(f
506\**Disclaimer: Some special processing is done
507after rewriting local names; see below.
508.)f
509.pp
510Although old style addresses are still accepted
511in most cases,
512the preferred address format
513is based on ARPANET-style domain-based addresses
514[Su82a].
515These addresses are based on a hierarchical, logical decomposition
516of the address space.
517The addresses are hierarchical in a sense
518similar to the U.S. postal addresses:
519the messages may first be routed to the correct state,
520with no initial consideration of the city
521or other addressing details.
522The addresses are logical
523in that each step in the hierarchy
524corresponds to a set of
525.q "naming authorities"
526rather than a physical network.
527.pp
528For example,
529the address:
530.(l
531eric@HostA.BigSite.ARPA
532.)l
533would first look up the domain
534BigSite
535in the namespace administrated by
536ARPA.
537A query could then be sent to
538BigSite
539for interpretation of
540HostA.
541Eventually the mail would arrive at
542HostA,
543which would then do final delivery
544to user
545.q eric.
546.sh 2 "Mail to Files and Programs"
547.pp
548Files and programs are legitimate message recipients.
549Files provide archival storage of messages,
550useful for project administration and history.
551Programs are useful as recipients in a variety of situations,
552for example,
553to maintain a public repository of systems messages
554(such as the Berkeley
555.i msgs
556program).
557.pp
558Any address passing through the initial parsing algorithm
559as a local address
560(i.e, not appearing to be a valid address for another mailer)
561is scanned for two special cases.
562If prefixed by a vertical bar (\c
563.q \^|\^ )
564the rest of the address is processed as a shell command.
565If the user name begins with a slash mark (\c
566.q /\^ )
567the name is used as a file name,
568instead of a login name.
569.sh 2 "Aliasing, Forwarding, Inclusion"
570.pp
571.i Sendmail
572reroutes mail three ways.
573Aliasing applies system wide.
574Forwarding allows each user to reroute incoming mail
575destined for that account.
576Inclusion directs
577.i sendmail
578to read a file for a list of addresses,
579and is normally used
580in conjunction with aliasing.
581.sh 3 "Aliasing"
582.pp
583Aliasing maps local addresses to address lists using a system-wide file.
584This file is hashed to speed access.
585Only addresses that parse as local
586are allowed as aliases;
587this guarantees a unique key
588(since there are no nicknames for the local host).
589.sh 3 "Forwarding"
590.pp
591After aliasing,
592if an recipient address specifies a local user
593.i sendmail
594searches for a
595.q .forward
596file in the recipient's home directory.
597If it exists,
598the message is
599.i not
600sent to that user,
601but rather to the list of addresses in that file.
602Often
603this list will contain only one address,
604and the feature will be used for network mail forwarding.
605.pp
606Forwarding also permits a user to specify a private incoming mailer.
607For example,
608forwarding to:
609.(b
610"\^|\|/usr/local/newmail myname"
611.)b
612will use a different incoming mailer.
613.sh 3 "Inclusion"
614.pp
615Inclusion is specified in RFC 733 [Crocker77] syntax:
616.(b
617:Include: pathname
618.)b
619An address of this form reads the file specified by
620.i pathname
621and sends to all users listed in that file.
622.pp
623The intent is
624.i not
625to support direct use of this feature,
626but rather to use this as a subset of aliasing.
627For example,
628an alias of the form:
629.(b
630project: :include:/usr/project/userlist
631.)b
632is a method of letting a project maintain a mailing list
633without interaction with the system administration,
634even if the alias file is protected.
635.pp
636It is not necessary to rebuild the index on the alias database
637when a :include: list is changed.
638.sh 2 "Message Collection"
639.pp
640Once all recipient addresses are parsed and verified,
641the message is collected.
642The message comes in two parts:
643a message header and a message body,
644separated by a blank line.
645The body is an uninterpreted
646sequence of text lines.
647.pp
648The header is formated as a series of lines
649of the form
650.(b
651	field-name: field-value
652.)b
653Field-value can be split across lines by starting the following
654lines with a space or a tab.
655Some header fields have special internal meaning,
656and have appropriate special processing.
657Other headers are simply passed through.
658Some header fields may be added automatically,
659such as time stamps.
660.sh 1 "THE UUCP PROBLEM"
661.pp
662Of particular interest
663is the UUCP network.
664The explicit routing
665used in the UUCP environment
666causes a number of serious problems.
667First,
668giving out an address
669is impossible
670without knowing the address of your potential correspondent.
671This is typically handled
672by specifying the address
673relative to some
674.q "well-known"
675host
676(e.g.,
677ucbvax or decvax).
678Second,
679it is often difficult to compute
680the set of addresses
681to reply to
682without some knowledge
683of the topology of the network.
684Although it may be easy for a human being
685to do this
686under many circumstances,
687a program does not have equally sophisticated heuristics
688built in.
689Third,
690certain addresses will become painfully and unnecessarily long,
691as when a message is routed through many hosts in the USENET.
692And finally,
693certain
694.q "mixed domain"
695addresses
696are impossible to parse unambiguously \*-
697e.g.,
698.(l
699decvax!ucbvax!lbl-h!user@LBL-CSAM
700.)l
701might have many possible resolutions,
702depending on whether the message was first routed
703to decvax
704or to LBL-CSAM.
705.pp
706To solve this problem,
707the UUCP syntax
708would have to be changed to use addresses
709rather than routes.
710For example,
711the address
712.q decvax!ucbvax!eric
713might be expressed as
714.q eric@ucbvax.UUCP
715(with the hop through decvax implied).
716This address would itself be a domain-based address;
717for example,
718an address might be of the form:
719.(l
720mark@d.cbosg.btl.UUCP
721.)l
722Hosts outside of Bell Telephone Laboratories
723would then only need to know
724how to get to a designated BTL relay,
725and the BTL topology
726would only be maintained inside Bell.
727.pp
728There are three major problems
729associated with turning UUCP addresses
730into something reasonable:
731defining the namespace,
732creating and propagating the necessary software,
733and building and maintaining the database.
734.sh 2 "Defining the Namespace"
735.pp
736Putting all UUCP hosts into a flat namespace
737(e.g.,
738.q \&...@host.UUCP )
739is not practical for a number of reasons.
740First,
741with over 1600 sites already,
742and (with the increasing availability of inexpensive microcomputers
743and autodialers)
744several thousand more coming within a few years,
745the database update problem
746is simply intractable
747if the namespace is flat.
748Second,
749there are almost certainly name conflicts today.
750Third,
751as the number of sites grow
752the names become ever less mnemonic.
753.pp
754It seems inevitable
755that there be some sort of naming authority
756for the set of top level names
757in the UUCP domain,
758as unpleasant a possibility
759as that may seem.
760It will simply not be possible
761to have one host resolving all names.
762It may however be possible
763to handle this
764in a fashion similar to that of assigning names of newsgroups
765in USENET.
766However,
767it will be essential to encourage everyone
768to become subdomains of an existing domain
769whenever possible \*-
770even though this will certainly bruise some egos.
771For example,
772if a new host named
773.q blid
774were to be added to the UUCP network,
775it would probably actually be addressed as
776.q d.bli.UUCP
777(i.e.,
778as host
779.q d
780in the pseudo-domain
781.q bli
782rather than as host
783.q blid
784in the UUCP domain).
785.sh 2 "Creating and Propagating the Software"
786.pp
787The software required to implement a consistent namespace
788is relatively trivial.
789Two modules are needed,
790one to handle incoming mail
791and one to handle outgoing mail.
792.pp
793The incoming module
794must be prepared to handle either old or new style addresses.
795New-style addresses
796can be passed through unchanged.
797Old style addresses
798must be turned into new style addresses
799where possible.
800.pp
801The outgoing module
802is slightly trickier.
803It must do a database lookup on the recipient addresses
804(passed on the command line)
805to determine what hosts to send the message to.
806If those hosts do not accept new-style addresses,
807it must transform all addresses in the header of the message
808into old style using the database lookup.
809.pp
810Both of these modules
811are straightforward
812except for the issue of modifying the header.
813It seems prudent to choose one format
814for the message headers.
815For a number of reasons,
816Berkeley has elected to use the ARPANET protocols
817for message formats.
818However,
819this protocol is somewhat difficult to parse.
820.pp
821Propagation is somewhat more difficult.
822There are a large number of hosts
823connected to UUCP
824that will want to run completely standard systems
825(for very good reasons).
826The strategy is not to convert the entire network \*-
827only enough of it it alleviate the problem.
828.sh 2 "Building and Maintaining the Database"
829.pp
830This is by far the most difficult problem.
831A prototype for this database
832already exists,
833but it is maintained by hand
834and does not pretend to be complete.
835.pp
836This problem will be reduced considerably
837if people choose to group their hosts
838into subdomains.
839This would require a global update
840only when a new top level domain
841joined the network.
842A message to a host in a subdomain
843could simply be routed to a known domain gateway
844for further processing.
845For example,
846the address
847.q eric@a.bli.UUCP
848might be routed to the
849.q bli
850gateway
851for redistribution;
852new hosts could be added
853within BLI
854without notifying the rest of the world.
855Of course,
856other hosts
857.i could
858be notified as an efficiency measure.
859.pp
860There may be more than one domain gateway.
861A domain such as BTL,
862for instance,
863might have a dozen gateways to the outside world;
864a non-BTL site
865could choose the closest gateway.
866The only restriction
867would be that all gateways
868maintain a consistent view of the domain
869they represent.
870.sh 2 "Logical Structure"
871.pp
872Logically,
873domains are organized into a tree.
874There need not be a host actually associated
875with each level in the tree \*-
876for example,
877there will be no host associated with the name
878.q UUCP.
879Similarly,
880an organization might group names together for administrative reasons;
881for example,
882the name
883.(l
884CAD.research.BigCorp.UUCP
885.)l
886might not actually have a host representing
887.q research.
888.pp
889However,
890it may frequently be convenient to have a host
891or hosts
892that
893.q represent
894a domain.
895For example,
896if a single host exists that
897represents
898Berkeley,
899then mail from outside Berkeley
900can forward mail to that host
901for further resolution
902without knowing Berkeley's
903(rather volatile)
904topology.
905This is not unlike the operation
906of the telephone network.
907.pp
908This may also be useful
909inside certain large domains.
910For example,
911at Berkeley it may be presumed
912that most hosts know about other hosts
913inside the Berkeley domain.
914But if they process an address
915that is unknown,
916they can pass it
917.q upstairs
918for further examination.
919Thus as new hosts are added
920only one host
921(the domain master)
922.i must
923be updated immediately;
924other hosts can be updated as convenient.
925.pp
926Ideally this name resolution process
927would be performed by a name server
928(e.g., [Su82b])
929to avoid unnecessary copying
930of the message.
931However,
932in a batch network
933such as UUCP
934this could result in unnecessary delays.
935.sh 1 "COMPARISON WITH DELIVERMAIL"
936.pp
937.i Sendmail
938is an outgrowth of
939.i delivermail .
940The primary differences are:
941.np
942Configuration information is not compiled in.
943This change simplifies many of the problems
944of moving to other machines.
945It also allows easy debugging of new mailers.
946.np
947Address parsing is more flexible.
948For example,
949.i delivermail
950only supported one gateway to any network,
951whereas
952.i sendmail
953can be sensitive to host names
954and reroute to different gateways.
955.np
956Forwarding and
957:include:
958features eliminate the requirement that the system alias file
959be writable by any user
960(or that an update program be written,
961or that the system administration make all changes).
962.np
963.i Sendmail
964supports message batching across networks
965when a message is being sent to multiple recipients.
966.np
967A mail queue is provided in
968.i sendmail.
969Mail that cannot be delivered immediately
970but can potentially be delivered later
971is stored in this queue for a later retry.
972The queue also provides a buffer against system crashes;
973after the message has been collected
974it may be reliably redelivered
975even if the system crashes during the initial delivery.
976.np
977.i Sendmail
978uses the networking support provided by 4.2BSD
979to provide a direct interface networks such as the ARPANET
980and/or Ethernet
981using SMTP (the Simple Mail Transfer Protocol)
982over a TCP/IP connection.
983.+c
984.ce
985REFERENCES
986.nr ii 1.5i
987.ip [Crocker77]
988Crocker, D. H.,
989Vittal, J. J.,
990Pogran, K. T.,
991and
992Henderson, D. A. Jr.,
993.ul
994Standard for the Format of ARPA Network Text Messages.
995RFC 733,
996NIC 41952.
997In [Feinler78].
998November 1977.
999.ip [Crocker82]
1000Crocker, D. H.,
1001.ul
1002Standard for the Format of Arpa Internet Text Messages.
1003RFC 822.
1004Network Information Center,
1005SRI International,
1006Menlo Park, California.
1007August 1982.
1008.ip [Feinler78]
1009Feinler, E.,
1010and
1011Postel, J.
1012(eds.),
1013.ul
1014ARPANET Protocol Handbook.
1015NIC 7104,
1016Network Information Center,
1017SRI International,
1018Menlo Park, California.
10191978.
1020.ip [Nowitz78]
1021Nowitz, D. A.,
1022and
1023Lesk, M. E.,
1024.ul
1025A Dial-Up Network of UNIX Systems.
1026Bell Laboratories.
1027In
1028UNIX Programmer's Manual, Seventh Edition,
1029Volume 2.
1030August, 1978.
1031.ip [Schmidt79]
1032Schmidt, E.,
1033.ul
1034An Introduction to the Berkeley Network.
1035University of California, Berkeley California.
10361979.
1037.ip [Shoens79]
1038Shoens, K.,
1039.ul
1040Mail Reference Manual.
1041University of California, Berkeley.
1042In UNIX Programmer's Manual,
1043Seventh Edition,
1044Volume 2C.
1045December 1979.
1046.ip [Solomon81]
1047Solomon, M.,
1048Landweber, L.,
1049and
1050Neuhengen, D.,
1051.ul
1052The Design of the CSNET Name Server.
1053CS-DN-2.
1054University of Wisconsin,
1055Madison.
1056October 1981.
1057.ip [Su82a]
1058Su, Zaw-Sing,
1059and
1060Postel, Jon,
1061.ul
1062The Domain Naming Convention for Internet User Applications.
1063RFC819.
1064Network Information Center,
1065SRI International,
1066Menlo Park, California.
1067August 1982.
1068.ip [Su82b]
1069Su, Zaw-Sing,
1070.ul
1071A Distributed System for Internet Name Service.
1072RFC830.
1073Network Information Center,
1074SRI International,
1075Menlo Park, California.
1076October 1982.
1077