| We know that m4 is only used within sendmail for generating the configuration file, sendmail.cfalthough as we've said before, this is the main task involved in getting mail working! The process to do this follows the same steps we used for our last example, only on a much greater scale. In other words, we pass a definition file and a small input file on to m4 and it creates the correct output file. All the definition files are supplied with sendmail in a directory named /usr/lib/mail. There are also a number of other files in here that help make all this work. Let's look at what's in there by default: hydrogen# cd /usr/lib/mail hydrogen# ls -l total 176 drwxrwxr-x 2 root mail 512 Aug 27 2000 cf drwxrwxr-x 2 root mail 512 Aug 27 2000 domain drwxr-xr-x 2 root mail 1536 Aug 27 2000 feature drwxr-xr-x 2 root mail 512 Aug 27 2000 m4 drwxr-xr-x 2 root mail 512 Aug 27 2000 mailer drwxr-xr-x 2 root mail 512 Aug 27 2000 ostype -r--r--r-- 1 root mail 81509 Sep 1 1998 README drwxr-xr-x 2 root mail 512 Aug 27 2000 sh hydrogen# The README file is probably the most important file to look at first. It describes the hierarchy, how to run the program, and, importantly, the macros that are available and the functionality of each one. The remaining directories are organized as follows: cf: Contains the template configuration file and stores the output produced domain: Domain definitions feature: Special features that may be included m4: General m4 definitions mailer: Definitions for different types of mailers ostype: Operating system definitions sh: Utility "check" programs
So, how do we use all this? Let's start by looking at one of the configuration files and work back from there to decipher what's happening. These are all located in the cf directory, which by default looks like the following: hydrogen# cd cf hydrogen# ls -l total 132 -r--r--r-- 1 root mail 27781 Sep 1 1998 main-v7sun.cf -r--r--r-- 1 root mail 2309 Sep 1 1998 main-v7sun.mc -r--r--r-- 1 root mail 2489 Sep 1 1998 Makefile -r--r--r-- 1 root mail 28407 Sep 1 1998 subsidiary-v7sun.cf -r--r--r-- 1 root mail 3255 Sep 1 1998 subsidiary-v7sun.mc hydrogen# All the files with a mc suffix are the templates (input files) that can be fed into m4. We can see that there is one named main-v7sun.mc and another named subsidiary-v7sun.mc. These are the template versions of the standard main.cf and subsidiary.cf files that are supplied by default in /etc/mail. All the files with a cf suffix are the output files that have been generated as a result of running m4 on the templates. Again, the main-v7sun.cf and subsidiary-v7sun.cf should be exactly the same as main.cf and subsidiary.cf in /etc/mail. The Makefile is supplied to help automate the build procedure if we wish, which means we don't have to remember the correct m4 commands that we should run (we discussed make and Makefiles in Chapter 12, "Naming Services and NIS"). We'll see how this is used later. Let's look at one of the input files nowwe'll use main-v7sun.mc as an example. We've removed the comments from it to make it smaller: hydrogen# cat main-v7sun.mc divert(-1) divert(0)dnl VERSIONID(`@(#)main-v7sun.mc 1.2 (Sun) 01/27/98') OSTYPE(solaris2.ml)dnl DOMAIN(solaris-generic)dnl MAILER(local)dnl MAILER(smtp)dnl hydrogen# That's it! When we run this through m4, it will generate a configuration file that is more than 1,000 lines long. All the commands we can see here are m4 directives, some of which are necessary, and others that are optional. Let's take one of these lines and follow it back to the m4 macroswe'll use the following line: OSTYPE(solaris2.ml)dnl This entry is used to set values for things such as help file path names and must be included in any configuration file. OSTYPE is a macro defined in the ostype directory. We've called it with an argument of solaris2.ml.m4, which means it will use the following file: hydrogen# cat /usr/lib/mail/ostype/solaris.ml.m4 divert(0) VERSIONID(`@(#)solaris2.ml.m48.8+1.2 (Berkeley+Sun) 05/19/98') divert(-1) define(`ALIAS_FILE', dbm:/etc/mail/aliases) ifdef(`HELP_FILE',, `define(`HELP_FILE', /etc/mail/sendmail.hf)') ifdef(`STATUS_FILE',, `define(`STATUS_FILE', /etc/mail/sendmail.st)') ifdef(`LOCAL_MAILER_PATH',, `define(`LOCAL_MAILER_PATH', `/usr/lib/mail.local')') ifdef(`LOCAL_MAILER_FLAGS',, `define(`LOCAL_MAILER_FLAGS', `fSmn9')') ifdef(`LOCAL_MAILER_ARGS',, `define(`LOCAL_MAILER_ARGS', `mail.local -d $u')') ifdef(`UUCP_MAILER_ARGS',, `define(`UUCP_MAILER_ARGS', `uux - -r -a$g $h!rmail ($u)')') define(`confCW_FILE', /etc/mail/sendmail.cw) define(`confEBINDIR', `/usr/lib')dnl hydrogen# We can see that this looks remarkably similar to our earlier example, defs.m4, which was used when we introduced m4only this one is a lot more complicated! We also notice a few common commands keep appearing in the input fileswe've already used define, and mentioned ifdef, but we can see that divert and dnl are also used often. Again, these are standard commands built into m4divert allows output redirection to be controlled, while dnl means "delete to new line" and is used to get rid of excess white space in the output. If we dig a little further and look at one of these definitions, we'll see where it has been used in the output file. For example, let's take the following entry from solaris2.ml.m4: ifdef(`LOCAL_MAILER_PATH',, `define(`LOCAL_MAILER_PATH', `/usr/lib/mail.local')') This essentially set the variable LOCAL_MAILER_PATH to the value of /usr/lib/mail.local, and will create the following entry in the relevant file: [View full width] Mlocal, P=/usr/lib/mail.local, F=lsDFMAw5:/|@qfSmn9, S=10/30, R=20/40, T=DNS/RFC822/  X-Unix, A=mail.local -d $u
Gosh! Now we can see why the macro is much easier to use. This also helps to highlight the second advantage of using m4automation; working through sendmail.cf checking for mistakes is nearly an impossible task. Generating the Configuration File Now we're ready to generate an output file. We haven't actually made any changes to anything yet; we'll do that in the next section. For now, we'll just see how to recreate the default template for a "main" machine. We know that we'll use m4 to do this, but we need to remember that a whole set of definitions must be included with itotherwise it won't know what to do! There are really two ways to perform the build. The first is by using the supplied Makefile. It includes everything required and so simply running make will generate the file. The second way is to build the file manually. It's not a complex task so we'll do that now; that way, we'll see how the main definitions are specified. First we need to be in the correct directory: hydrogen# cd /usr/lib/mail/cf hydrogen# m4 ../m4/cf.m4 main-v7sun.mc > main-v7sun.cf hydrogen# This shows that we've passed two files into m4; the first is the top-level definition file, cf.m4. This automatically pulls in all the other subfiles as necessary. The second file is our input, main-v7sun.mc. So, what would have happened if we had used the Makefile instead? Let's do that now and find out! hydrogen# make main-v7sun.cf /usr/bin/mv main-v7sun.cf main-v7sun.cf.prev /usr/ccs/bin/m4 ../m4/cf.m4 main-v7sun.mc > main-v7sun.cf hydrogen# There are two differences we can spot. The first is that if the output file already exists, it will rename it and save it. The second is that m4 is called using its full path name, which helps get around the problem with the "PATH" that we mentioned earlier. Once the correct file has been generated, we simply need to replace the current configuration file, /etc/mail/sendmail.cf, with the new copy, and restart the daemons for the changes to take effect. The following commands would do this for us: hydrogen# cp /etc/mail/sendmail.cf /etc/mail/sendmail.cf.orig hydrogen# cp ./main-v7sun.cf /etc/mail/sendmail.cf hydrogen# /etc/init.d/sendmail stop hydrogen# /etc/init.d/sendmail start hydrogen# Adding Functionality Now that we've seen that we can easily recreate the main.cf and subsidiary.cf configuration files, let's look at what we would need to do if we require anything else. For example, we may want to add virus-checking software or perhaps alter some of the "rules" that sendmail uses. Additional functionality is commonly added through the use of a macro known as the "FEATURE" macro. This allows us to easily enable or customize some of the sendmail facilities. There are lots of "features" available, but the downside of this is that the only real way to find out which you need is by reading through the README file we mentioned before. This information is also replicated on the sendmail Web site (www.sendmail.org). For example, if we wanted to include the local host domain, even on internal mail, we could do this with the following code: FEATURE(always_add_domain) Similarly, the following entry means, "don't do anything special with UUCP addresses": FEATURE(nouucp) If we also look in the subsidiary template file, we'll see that it contains the following: hydrogen# cat subsidiary-v7sun.mc divert(0)dnl VERSIONID(`@(#)subsidiary-v7sun.mc 1.7 (Sun) 05/27/00') OSTYPE(solaris2)dnl DOMAIN(solaris-generic)dnl FEATURE(`remote_mode')dnl define(`SMART_HOST', `mailhost.$m') MAILER(local)dnl MAILER(smtp)dnl hydrogen# This shows that the feature "remote_mode" has been enabled and the variable SMART_HOST has been defined. These are both features that are used to control mail flow. For example, SMART_HOST sets the name of the relay that all outgoing mail will be sent to. Once these features have been added to the file, we need to follow exactly the same steps we did to build and use the "main" file. Now let's move on and build the actual systems. | 
