![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to README CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [CSRG BSD Unix] / 43BSDReno / usr.sbin / sendmail / cf|
Return to README CVS log | Up to [CSRG BSD Unix] / 43BSDReno / usr.sbin / sendmail / cf |
1.1 root 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, [email protected], ...!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 "[email protected]".
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 "[email protected]" 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 "[email protected]" are
214: considered to be the basic type of address we deal with.
215:
216: * Fake domains. Addresses of the form:
217:
218: [email protected]
219: and
220: [email protected]
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: "[email protected]" 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%[email protected]
256:
257: If not defined, outgoing addresses will always be of the form
258:
259: [email protected]
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 [email protected]) is forwarded. If not defined,
304: addresses of the form "[email protected]" 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 [email protected]) 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., [email protected]) 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.
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.