Commit | Line | Data |
---|---|---|
15637ed4 RG |
1 | INTRODUCTION: |
2 | ------------- | |
3 | ||
4 | This document describes (in some detail, though undoubtedly not enough!) | |
5 | the sendmail configuration files currently in use at Berkeley as distributed | |
6 | with version 5.61 of sendmail. It discusses the configuration file | |
7 | directory hierarchy, how the files are processed by m4(1), what functionality | |
8 | the files provide, what m4(1) options can be used to produce specific | |
9 | results, and goes through an example or two. It concludes with a list | |
10 | of things that will change in the next release of the configuration files. | |
11 | ||
12 | This is a working draft; your comments are appreciated. Please send your | |
13 | suggestions to Phil Lapsley, phil@ucbvax.berkeley.edu, ...!ucbvax!phil. | |
14 | ||
15 | ||
16 | HIERARCHY: | |
17 | ---------- | |
18 | ||
19 | The "cf" subdirectory is organized as follows: | |
20 | ||
21 | cf | |
22 | | | |
23 | +---------------+---------------+ | |
24 | | | | | |
25 | sitedep m4 cf | |
26 | | | / \ | |
27 | *.m4 *.m4 *.mc *.cf | |
28 | ||
29 | where the directories contain the following: | |
30 | ||
31 | sitedep Site dependent parts of configuration files | |
32 | in m4(1) include files. | |
33 | ||
34 | m4 Site independent parts of configuration files | |
35 | in m4(1) include files. | |
36 | ||
37 | cf Includes "master configuration" (.mc) files | |
38 | that include m4 files from ../m4 and ../sitedep. | |
39 | .mc files are processed by m4(1) and result in | |
40 | configuration files (.cf). | |
41 | ||
42 | In the remainder of this document, all path names are referenced | |
43 | relative to the top level "cf" directory. Hence, the m4 subdirectory | |
44 | is called "cf/m4". | |
45 | ||
46 | ||
47 | WHERE m4(1) FITS INTO ALL OF THIS: | |
48 | ---------------------------------- | |
49 | ||
50 | Configuration files are built by typing "make" in cf/cf. This | |
51 | runs m4(1) on the .mc files in cf/cf and produces .cf files. | |
52 | ||
53 | The philosophy at Berkeley is to place as much information into | |
54 | one .mc file as possible, and then use m4 conditional substitution | |
55 | (ifdef, for example) to produce other configuration files from it. | |
56 | This results in a substantial reduction of duplicated code that must | |
57 | be maintained separately. | |
58 | ||
59 | The main master configuration file that contains all this information | |
60 | is "cf/proto.mc". This file has a number of m4 conditional substitutions | |
61 | that can be controlled by other .mc files that include "cf/proto.mc". | |
62 | ||
63 | For example, most hosts at Berkeley have only SMTP (TCP) connections | |
64 | to other hosts. A file called "ucbproto.cf" takes care of these | |
65 | machines by defining the m4 flags needed to produce only SMTP mailer | |
66 | definitions from "cf/proto.mc". Since this is default behavior, very | |
67 | little needs to be defined. | |
68 | ||
69 | But some hosts at Berkeley (e.g., cad.Berkeley.EDU) have both SMTP | |
70 | connections and UUCP connections as well. Thus, they need to | |
71 | produce a configuration file that contains both SMTP and UUCP mailer | |
72 | definitions, and they need to include a list of directly connected | |
73 | UUCP neighbors. The file "cf/cad.mc" does this by setting the m4 | |
74 | flags for "cf/proto.mc" that say "(1) I am a UUCP host with hostname "ucbcad", | |
75 | (2) a list of my UUCP neighbors can be found in ../sitedep/uucp.cad.m4". | |
76 | ||
77 | Thus, there are many .mc files in cf/cf that simply define m4 flags and | |
78 | then include "cf/proto.mc" to produce a specific configuration file. | |
79 | ||
80 | Note: | |
81 | ||
82 | IT IS STRONGLY SUGGESTED THAT YOU, THE SYSTEM MANAGER, | |
83 | CONTINUE TO MAINTAIN CONFIGURATION FILES BY USING THIS | |
84 | m4(1) METHOD. TRYING TO MAINTAIN MULTIPLE .CF FILES | |
85 | ON SEPARATE MACHINES WILL LEAD TO INSANITY. | |
86 | ||
87 | ||
88 | With that out of the way, we should now examine the functionality | |
89 | provided by the supplied sendmail configuration files, and then | |
90 | talk in detail about the m4(1) options that control this. | |
91 | ||
92 | FUNCTIONALITY PROVIDED BY THE SUPPLIED SENDMAIL CONFIGURATIONS: | |
93 | --------------------------------------------------------------- | |
94 | ||
95 | Mailers: | |
96 | -------- | |
97 | ||
98 | The sendmail configuration files come with the following mailers: | |
99 | ||
100 | local For delivery of messages to users on the | |
101 | local machine. | |
102 | ||
103 | tcp For SMTP delivery of messages across the | |
104 | the Internet. | |
105 | ||
106 | tcpld For SMTP delivery of messages within the | |
107 | local domain. | |
108 | ||
109 | uucp For delivery of messages to a UUCP neighbor. | |
110 | ||
111 | smtpuucp For delivery of messages to a UUCP neighbor | |
112 | with whom we also share Internet connectivity. | |
113 | ||
114 | The tcp/tcpld mailers and the smtpuucp mailers deserve a little more | |
115 | explanation. | |
116 | ||
117 | The "tcp" and "tcpld" mailers: | |
118 | ------------------------------ | |
119 | ||
120 | As regards tcp and tcpld: in theory, there should be only one mailer | |
121 | here, called "smtp", that deals with addresses in the form "user@host.domain". | |
122 | Everyone on the Internet would use this, regardless of what domain | |
123 | they were in. Host name lookups would be performed via the domain naming | |
124 | system (DNS), and no central registry of machine names would be necessary. | |
125 | ||
126 | Unfortunately, this is not the case. The MILNET community is still | |
127 | in transition towards the DNS, and until this transition is complete, | |
128 | they do not have to use the nameserver. Rather, they can "legally" | |
129 | still use the host table supplied by SRI-NIC to translate names to | |
130 | addresses. This means that to be strictly legal, we must send out | |
131 | messages in the form "user@host.domain" ONLY FOR machines that are | |
132 | registered with SRI NIC. Machines that are not registered with the | |
133 | NIC must be "hidden" behind a relay machine, e.g., | |
134 | user%unregistered_host@registered_host.domain. This, when MILNET folks | |
135 | reply to this, the mail passes through "registered_host.domain" first. | |
136 | ||
137 | Currently this "hiding" behind NIC registered hosts is performed by | |
138 | the "tcp" mailer. | |
139 | ||
140 | Since you don't want to register all the hosts at your site with | |
141 | the NIC (and they don't want you to!), the "tcpld" mailer was created. | |
142 | The idea here is that you KNOW all the hosts in your local domain | |
143 | use the nameserver, so there is no need to hide mail behind a NIC | |
144 | registered relay -- that would only slow things down. So the "tcpld" | |
145 | does not do any hiding of unregistered hosts behind a registered relay. | |
146 | ||
147 | Eventually the "tcpld" mailer will become the "smtp" mailer mentioned above. | |
148 | ||
149 | The "smtpuucp" mailer: | |
150 | ---------------------- | |
151 | ||
152 | The "smtpuucp" mailer is another fun one. As time progresses, many | |
153 | hosts with whom one has UUCP connections join the Internet. Unfortunately, | |
154 | if the UUCP connection existed for any length of time, people are | |
155 | probably used to using it, complete with the bangist syntax that comes | |
156 | with UUCP. As a result, many sites elect to keep their | |
157 | UUCP connections even though they have TCP/IP connectivity to the sites | |
158 | in question. This turns out not be such a good idea because of the | |
159 | double-queuing incurred by UUCP, explained in the following example. | |
160 | ||
161 | For concreteness, consider the following scenario: ucbvax.Berkeley.EDU | |
162 | (UUCP host "ucbvax") and decvax.dec.com (UUCP host "decvax") have shared | |
163 | a cross county UUCP link that is heavily used by many people. Let's say | |
164 | that a piece of mail is routed through the ucbvax-decvax link via UUCP. | |
165 | The queueing process is: | |
166 | ||
167 | ||
168 | step host action | |
169 | ----- ----- ------ | |
170 | 1 ucbvax incoming mail is accepted via UUCP | |
171 | 2 ucbvax uuxqt is queued to invoke sendmail. | |
172 | 3 ucbvax sendmail parses the message. | |
173 | 4 ucbvax sendmail passes the message to the UUCP | |
174 | mailer for delivery to decvax. | |
175 | 5 ucbvax message is placed in the outgoing UUCP queue for decvax | |
176 | ||
177 | 6 decvax uucico takes the message from ucbvax | |
178 | 7 decvax uuxqt is queued to invoke sendmail | |
179 | 8 decvax sendmail parses the message | |
180 | 9 decvax sendmail passes the message to someplace else. | |
181 | ||
182 | Note that the message transited the inbound UUCP queue on ucbvax, the sendmail | |
183 | queue on ucbvax, the outbound UUCP queue on ucbvax, the inbound UUCP queue | |
184 | on decvax, etc. | |
185 | ||
186 | Now, if decvax and ucbvax have SMTP connectivity, the session is more | |
187 | manageable: | |
188 | ||
189 | step host action | |
190 | ----- ----- ------ | |
191 | 1 ucbvax incoming mail is accepted via UUCP | |
192 | 2 ucbvax uuxqt is queued to invoke sendmail. | |
193 | 3 ucbvax sendmail parses the message | |
194 | 4a ucbvax sendmail delivers it to decvax.dec.com via SMTP. | |
195 | ||
196 | a decvax sendmail accepts the message from ucbvax via SMTP. | |
197 | 8 decvax sendmail parses the message. | |
198 | 9 decvax sendmail passes it to someplace else. | |
199 | ||
200 | Note that old steps (5) and (7), the UUCP queueing, are avoided entirely. | |
201 | ||
202 | The only trick to the "smtpuucp" mailer is that even though it uses | |
203 | SMTP to communicate with its neighbors, it must use the UUCP syntax | |
204 | and rewriting rulesets so that the operation is transparent to the | |
205 | outside world. This is easy enough to do. | |
206 | ||
207 | Other functionality: | |
208 | ------------------- | |
209 | ||
210 | Aside from the mailers supplied, the basic configuration files | |
211 | support the following features: | |
212 | ||
213 | * Domains. Addresses of the form "user@host.domain" are | |
214 | considered to be the basic type of address we deal with. | |
215 | ||
216 | * Fake domains. Addresses of the form: | |
217 | ||
218 | user@host.BITNET | |
219 | and | |
220 | user@host.CSNET | |
221 | ||
222 | are forwarded to a CSNET relay host and a BITNET relay host, | |
223 | respectively. | |
224 | ||
225 | Note: this feature exists for convenience. As CSNET and | |
226 | BITNET convert to domains, it will go away. In particular, | |
227 | "user@host.CSNET" is slated to get the axe in the next release. | |
228 | ||
229 | m4(1) OPTIONS USED IN THE .MC FILES: | |
230 | ------------------------------------ | |
231 | ||
232 | The following options, from "most important" to "trivial", can be | |
233 | used to control what configuration file you get from running m4(1) | |
234 | on "cf/proto.mc". As explained earlier, the standard practice is to | |
235 | create an ".mc" file for a particular configuration that contains | |
236 | all the m4(1) macro definitions/flags you want, and then have | |
237 | that .mc file include "mc/proto.mc". | |
238 | ||
239 | Macro name Example (you must include the ` and ')! | |
240 | ---------- --------------------------------------- | |
241 | ||
242 | DOMAIN `DDBerkeley.EDU' | |
243 | ||
244 | This MUST be defined to be your Internet domain. | |
245 | ||
246 | INTERNET_RELAY `DAcad.Berkeley.EDU' | |
247 | ||
248 | If defined, this will be the machine behind which non-NIC registered | |
249 | hosts are hidden, resulting in addresses of the form | |
250 | ||
251 | user%host@internet_relay.domain | |
252 | ||
253 | e.g., | |
254 | ||
255 | moore%prefect@cad.Berkeley.EDU | |
256 | ||
257 | If not defined, outgoing addresses will always be of the form | |
258 | ||
259 | user@host.domain | |
260 | ||
261 | regardless of whether "host.domain" is registered with the NIC. | |
262 | ||
263 | UUCP_NAME `DUucbcad' | |
264 | ||
265 | If defined, includes the UUCP mailer and assumes you have local | |
266 | UUCP connections. The UUCP_NAME macro is used to define your | |
267 | canonical UUCP hostname. See also: UUCP_ALIASES and UUCP_HOSTS_FILE. | |
268 | ||
269 | UUCP_ALIASES `CUucbcad cad' | |
270 | ||
271 | Used only if UUCP_NAME is defined, this macro lists any UUCP | |
272 | aliases for your machine. See also: UUCP_NAME and UUCP_HOSTS_FILE. | |
273 | ||
274 | UUCP_HOSTS_FILE `../sitedep/uucp.cad.m4' | |
275 | ||
276 | Used only if UUCP_NAME is defined. Defines class V of | |
277 | local UUCP hosts by including the appropriate m4 file. See also: | |
278 | UUCP_NAME and UUCP_ALIASES. | |
279 | ||
280 | UUCP_RELAY `DRcad.Berkeley.EDU' | |
281 | ||
282 | If defined, this will be the machine to which non-local UUCP traffic | |
283 | is forwarded. That is, any address that ends in ".UUCP" that is | |
284 | not listed in the V class (as defined by UUCP_HOSTS_FILE) will be | |
285 | forwarded to the UUCP_RELAY host via the "tcpld" mailer. | |
286 | ||
287 | UUCP_ONLY 1 | |
288 | ||
289 | If defined, makes sure that no TCP/IP based mailers will be | |
290 | put in the resulting configuration file. Normally undefined. | |
291 | ||
292 | SMTPUUCP `../sitedep/smtpuucp.cad.m4' | |
293 | ||
294 | If defined, use SMTP to resolve certain UUCP connections (while | |
295 | keeping UUCP syntax). Should be defined to be a file that | |
296 | contains the list of pairs of UUCP names and their corresponding | |
297 | Internet names. See "machdep/smtpuucp.ucbvax.m4" for an example | |
298 | of what this should look like. | |
299 | ||
300 | BITNET_RELAY `DBjade.Berkeley.EDU' | |
301 | ||
302 | If defined, this will be the machine to which BITNET traffic | |
303 | (i.e., mail to user@host.bitnet) is forwarded. If not defined, | |
304 | addresses of the form "user@host.bitnet" will bounce. | |
305 | ||
306 | CSNET_RELAY `DCrelay.cs.net' | |
307 | ||
308 | If defined, this will be the machine to which CSNET traffic | |
309 | (i.e., mail to user@host.csnet) is forwarded. If not defined, addresses | |
310 | of that form will bounce. | |
311 | ||
312 | ARPAKLUDGE `1' | |
313 | ||
314 | If defined, this turns on a kludge to reduce mail load on your | |
315 | INTERNET_GATEWAY. What is done is the following: if mail is outgoing | |
316 | to a machine in the ".arpa" domain and we're not registered with the | |
317 | NIC, we hide ourselves behind our INTERNET_GATEWAY. If the machine | |
318 | to which mail is being delivered is NOT in the ".arpa" domain, we | |
319 | assume they use the domain name system and can reply to our address -- | |
320 | hence, we don't hide anywhere. | |
321 | ||
322 | AN EXAMPLE OR TWO: | |
323 | ------------------ | |
324 | ||
325 | Let's consider a hypothetical system at Foo, Inc. Foo, Inc. is on the | |
326 | ARPA Internet and is the proud owner of the domain "foo.com". Machines | |
327 | in "foo.com" exchange mail with other hosts on the Internet via SMTP. | |
328 | Foo, Inc. also has customers with whom they have UUCP links -- these | |
329 | links are all on the machine "uucp-gw.foo.com". Mail to any address | |
330 | that ends in ".UUCP" should be forwarded to "uucp-gw.foo.com". They | |
331 | also have a gateway to the bitnet through their local machine | |
332 | "bitnet-gw.foo.com"; mail to any address ending in ".bitnet" should go | |
333 | there. They intend to take advantage of the kind folks at CSNET by | |
334 | forwarding mail to "host.csnet" to the machine "relay.cs.net". | |
335 | ||
336 | The master configuration file for a generic machine on the corporate | |
337 | ethernet might look like this: | |
338 | ||
339 | define(DOMAIN, `DDfoo.com') | |
340 | define(UUCP_RELAY, `DRuucp-gw.foo.com') | |
341 | define(BITNET_RELAY, `DBbitnet-gw.foo.com') | |
342 | define(CSNET_RELAY, `DCrelay.cs.net') | |
343 | include(proto.mc) | |
344 | ||
345 | And that's it! The system manager at "foo.com" would simply install | |
346 | this in the "cf" subdirectory, add a production to the make file, | |
347 | and type "make foo.cf". This would run m4(1) on the .mc file and | |
348 | we're done. | |
349 | ||
350 | Now let's turn to the machine "uucp-gw.foo.com". It obviously needs | |
351 | to have the UUCP mailer compiled in, and it needs a list of UUCP | |
352 | neighbors with whom it is connected. Of course, it also needs a TCP/IP | |
353 | (SMTP) based mailer so it can talk to the rest of the company. | |
354 | On the UUCP network, "uucp-gw.foo.com" is known as "foo". | |
355 | The master configuration file might be: | |
356 | ||
357 | define(DOMAIN, `DDfoo.com') | |
358 | define(UUCP_NAME, `DUfoo') | |
359 | define(UUCP_ALIASES, `CUfoo') | |
360 | define(UUCP_HOSTS_FILE, `../sitedep/uucp.foo.m4') | |
361 | define(BITNET_RELAY, `DBbitnet-gw.foo.com') | |
362 | define(CSNET_RELAY, `DCrelay.cs.net') | |
363 | include(proto.mc) | |
364 | ||
365 | Note that we didn't define UUCP_RELAY here, since we ARE the UUCP relay. | |
366 | ||
367 | The file "../sitedep/uucp.foo.m4" contains a list of our UUCP neighbors: | |
368 | ||
369 | CV oink | |
370 | CV bletch | |
371 | CV spam | |
372 | ||
373 | indicating that "uucp-gw.foo.com" is directly connected to three other | |
374 | machines via UUCP: "oink", "bletch", and "spam." | |
375 | ||
376 | ||
377 | WHAT WILL BE CHANGING IN THE NEXT RELEASE: | |
378 | ------------------------------------------ | |
379 | ||
380 | In the next release, the following things should change: | |
381 | ||
382 | 1. The MILNET should have gotten its act together. This means | |
383 | that the "tcp" mailer goes away. The "tcpld" mailer will | |
384 | be renamed "smtp". The "N" class (NIC registered hosts) | |
385 | gets axed. The ARPAKLUDGE and INTERNET_RELAY m4(1) options | |
386 | will disappear as well. | |
387 | ||
388 | 2. The CSNET "fake domain" (i.e., user@host.csnet) will cease | |
389 | to be supported. | |
390 | ||
391 | 3. The "smtp" mailer rulesets (currently 17/27) will be rewritten, | |
392 | along with much of rulesets 0 and 3. |