![[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.