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