![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to Domains CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [MW Coherent from dump] / coherent / d / bin / mail / smail / docs|
Return to Domains CVS log | Up to [MW Coherent from dump] / coherent / d / bin / mail / smail / docs |
1.1 root 1: WHAT YOU NEED TO KNOW ABOUT PATHALIAS
2: AND WHAT PATHALIAS NEEDS TO KNOW ABOUT YOU
3: or
4: HOW PATHALIAS MAKES DOMAINS
5:
6: Christopher Seiwald
7:
8: This note describes the host connectivity data and domain data
9: needed to effect UUCP domain-style address routing. This
10: describes mostly the domain data, but also discusses how to
11: distribute connectivity data. Look elsewhere for a discussion of
12: domains.
13:
14: Briefly, the connectivity data (what's in mod.map) connects
15: all hosts in the UUCP network into one big directed graph, and
16: the domain data superimposes a domain tree onto that graph.
17: Pathalias converts these two sets of data into a routing database
18: which smail/rmail, a UUCP mail routing program, uses.
19:
20: 1. Domains and Gateways for UUCP
21:
22: For domains in the UUCP zone, the top of a subdomain is all
23: gateway hosts for that domain; the top of the UUCP zone will
24: probably be nearly a hundred hosts. As a transition aid, we
25: also consider an individual host at the bottom of the domain tree a
26: subdomain "host.UUCP", with one gateway and no further subdomains.
27: (We expect to phase this out eventually.)
28:
29: A gateway host for a domain must do four things:
30: I) Pass mail bound for that domain to the
31: appropriate host.
32: II) Pass mail bound for outside that domain to a
33: gateway in the parent domain.
34: III) Pass mail bound for a subdomain to a gateway of
35: that subdomain.
36: IV) Recognise the domain!user address syntax.
37:
38: smail/rmail already provides (IV). With the data described here,
39: pushed through pathalias, smail/rmail can then provide (I)-(III).
40:
41: 2. The Zone Registry
42:
43: For any sizeable zone, one gateway host supports the zone registry.
44: For other zones, such as BITNET, CSNET, DDN, etc., registries are
45: supported, using conventions appropriate to those zones. Contact
46: electronic mail addresses are supported for queries, and updates to
47: configuration information may also be handled via mail. In the UUCP
48: zone, the id's "[email protected]" and "[email protected]"
49: serve to collect the connectivity and domain data, respectively, for
50: that zone.
51:
52: The registry for a zone speaks for that zone, communicating
53: chiefly with its peers, the registry of the parent domain, and
54: the registries of the subdomains.
55:
56: 3. Functions of Domain Data
57:
58: Each gateway for a domain must map the domain-style names into
59: the UUCP host names for all hosts of the domain. This host name
60: mapping provides (I) above.
61:
62: Each gateway for a domain knows a) at least one gateway for each
63: immediate subdomain, and b) at least one gateway host of the
64: parent domain. This provides (II) and (III) above.
65:
66: For consistency across the gateways of a domain, each gateway for
67: the domain should know a) ALL gateways for each immediate
68: subdomain; and b) ALL gateways for the parent domain. Pathalias
69: will pick the closest. In this way, one single database can
70: describe the domain structure for all gateways on a domain,
71: without variations for each gateway.
72:
73: In order to aid routing and avoid overloading the parent gateway,
74: gateways should also know most gateways for peer level domains.
75: This information is also provided by the map and used by pathalias.
76: When a new peer domain is created, traffic can be routed through the
77: parent (which must be updated immediately) until information about
78: the peer can be propagated.
79:
80: Additionally, a gateway could know about domains more than one
81: level above or below it so that mail doesn't stop for address
82: resolution at every gateway along its path.
83:
84: 4. Format of Domain Data
85:
86: 4.1 Host Name List
87:
88: The host name list aliases the domain style address of a host to
89: the UUCP host name. The pathalias input format is:
90:
91: uucp-name .domain-name[, ...]
92:
93: The .UUCP suffix is implicit in the uucp-name (smail/rmail does
94: this), and is not needed.
95: Upper/lower case doesn't matter in a dotted domain name.
96: Examples:
97:
98: ihnp4 = .ATT.COM
99: ucbvax = .Berkeley.EDU
100: cbosgd = .osgd.cb.att.com, .cbosgd.att.com
101:
102: Might produce from pathalias:
103:
104: ihnp4 mtxinu!ihnp4!%s
105: .ihnp4.ATT.COM mtxinu!ihnp4!%s
106: ucbvax ucbvax!%s
107: .Berkeley.EDU ucbvax!%s
108: cbosgd cbosgd!%s
109: .osgd.cb.att.com cbosgd!%s
110: .cbosgd.att.com cbosgd!%s
111:
112: A single host may have more than one domain style address; in
113: fact, a host may be in several domains at once. However, each
114: host must have a single primary location in the domain tree,
115: and other addresses should be viewed as transition aids. For
116: example, cbosgd might be known as cbosgd, cbosgd.UUCP,
117: cbosgd.ATT.UUCP, cbosgd.btl.csnet, and cbosgd.ATT.COM, but
118: the primary name is the one in the organizational domain (COM)
119: which applies to all networks, and the others are temporary
120: names for upward compatibility only.
121:
122: 4.2 Domain Gateway List
123:
124: The domain gateway list aliases the domain style address of a
125: domain to the UUCP host name of the closest gateway of that
126: domain. This involves a trick in pathalias, and employs a
127: extra network name domain-gw. The pathalias input format is:
128:
129: domain-gw .domain-name
130:
131: Again, the .UUCP suffix is implicit in the uucp-name, and is
132: not needed.
133: Examples:
134:
135: decwrl .DEC.COM
136: decuac .DEC.COM
137:
138: cbosgd .ATT.COM
139: clyde .ATT.COM
140:
141: Might generate from pathalias:
142:
143: .DEC.COM seismo!decuac!%s
144: .ATT.COM cbosgd!%s
145:
146: Note that pathalias chooses the closest host from inside the {}'s.
147: The (DEAD)'s prevent pathalias from following along the mock network
148: called "domain-gw".
149:
150: 5. Distribution of Domain Data
151:
152: A zone registry maintains a Host Name List (in the format of 4.1
153: above) of all hosts within its domain and a Domain Gateway List
154: (in the format of 4.2 above) of all gateways of the domain.
155:
156: Up: A registry collects the Domain Gateway List from the registry
157: of each of its subdomains, and transmits to the registry of its
158: parent domain its own Domain Gateway List and, if it chooses, the
159: Domain Gateway Lists of some or all of its subdomains. Whether
160: it includes lists from its subdomains depends on how important it
161: considers them to the parent domain.
162:
163: Down: Similarly, a registry collects the Domain Gateway List from
164: the registry of its parent domain, and transmits to the registry
165: of each of its subdomains its Domain Gateway List and the Domain
166: Gateway List of its parent domain. Note that the Domain Gateway
167: List of the parent domain may include lists from the parent's
168: other subdomains.
169:
170: A registry may decide not to use the parent domain's Domain
171: Gateway List or not to transmit it to its subdomains' registries.
172: (This should be done only with the consent of the subdomains.) In
173: this case, the registry must introduce a domain gateway alias for
174: all top level domains, to ensure that all the mail gets delivered.
175:
176: Across: a registry transmits to each of the gateways of its
177: domain its Host Name List, its Domain Gateway List, and collected
178: Domain Gateway Lists. The registry also transmits to each normal
179: host (one gateway, no subdomains) of its domain its Domain
180: Gateway List.
181:
182: Together, "up," "down," and "across" insure that each gateway has
183: the Host Name List for its domain, and the Domain Gateway List of
184: its own domain and at least its parent domain and subdomains.
185: "Up" and "across" will probably take place on demand by mail.
186: "Down" will probably be broadcast via netnews on a regular
187: schedule. In particular, the second level information for the UUCP
188: zone (one entry per organization) and the complete top level domain
189: information make up the postings to mod.map.
190:
191: 6. Distribution of Connectivity Data
192:
193: The distribution of connectivity data will probably follow the
194: path of domain data: registries passing connectivity data up,
195: down, and across the domain tree, with the exception that the
196: connectivity within a third (or lower) level domain will be
197: discouraged from leaving the domain, so the data the UUCP zone
198: registry distributes will include only the first and second
199: level gateways. Local information about internal subdomains and
200: machines of organizations should not be included in globally
201: published information, but rather distributed locally as needed.
202:
203: 7. Various Notes
204:
205: The following are examples of data that should be joined together
206: as input to pathalias.
207:
208: Parent Domain Gateway List
209: Parent Connectivity Data
210: This Level Domain Gateway List
211: This Level Host Name List
212: This Level Connectivity Data
213: Collected Subdomains' Domain Gateway Lists
214: Collected Subdomains' Connectivity Data
215: Private Additions
216: Alias for "this host"
217:
218: This note does not describe the inclusion of private additions to
219: the domain or connectivity data.
220:
221: Because domain names intermix with host names (and the .UUCP
222: suffix is implicit), you can address hosts known at your gateway
223: as "uucp-host.UUCP". We discourage this, because the address is
224: then particular to the sender's location.
225:
226:
227: /+\
228: 5/1/85 +\ [email protected]
229: \+/
230:
231: [Updated 5/9/86 by Mark Horton.]
232: #
233: #@(#)Domains 2.5 (smail) 9/15/87
234: #
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.