2.4 Why Use M4?

Especially when someone is just starting to use M4, it can be irritating to pore through the cf/README file to find the option or macro one needs to modify sendmail's behavior. What exactly is a macro and what isn't? Why are some things set using define() and some using FEATURE()? Trying to understand this syntax can prove very frustrating, especially if one knows exactly which line or lines in the sendmail.cf file need to be changed, but can't figure out how to do it in M4. Nevertheless, consistently doing things via M4 will pay off through the long-term maintainability of the email servers.

Each new version of sendmail includes many new features. Additionally, because much more field test time has accumulated and Internet services have generally evolved, occasional small bugs or better ideas prompt revisions, usually minor, of the sendmail rules. Over time, a given sendmail.cf file will fall further out of date with respect to the feature set available within sendmail as well as what is considered best practice in terms of processing email. For this reason, it's desirable to update the sendmail.cf file with each installation of a new revision of sendmail.

If a configuration template is written in M4, then upgrading is as simple as copying the .mc file to the cf/cf directory of the new distribution tree and using make to generate an updated file. To see how different the resulting .cf files might be, try this technique with two significantly different versions of sendmail, such as 8.11.6 and 8.12.2. Generate two .cf files using these different source distributions but the same .mc file, and then run the UNIX diff utility to find out how much the output has changed. Porting these changes by directly editing the sendmail.cf file would involve much more work than figuring out how to express a configuration in M4, even for a true sendmail guru.

Directly modifying a sendmail.cf file is an almost certain way to create a legacy system, starting down the road to a long-term support nightmare. Someone will almost certainly regret this decision later. Even if the effort is fairly well documented, it's just so much easier to understand what has changed, what the intent was, and what the side effects might be in a 20- to 50-line M4 file than in a 1500- to 2000-line sendmail.cf file. Managing updates to the file with a version control system can help a great deal. Of course, even at the most disciplined sites, harried system administrators do not always check updates into the version control systems, and version control logs are occasionally neglected as configurations migrate from one machine to another. On occasion, I've been contracted to help upgrade an email server running off an ancient configuration file because someone hacked it to do something necessary, didn't document what was done and why clearly enough, and then left the company. Undoing this damage can prove far more expensive than doing things right the first time.

I have to admit, sometimes I might want to test a very minor configuration change and I really don't want to go to the effort of generating the new file using M4, or I might not know what the correct syntax will be so I want to test and iterate on the configuration before writing it out in M4. In those cases, even though I know it's the wrong thing to do, I will manually edit the sendmail.cf file, albeit with the intention of changing it back immediately after the test ends. Then, once I know exactly what I want, I'll make the change to the .mc file. Unfortunately, it's human nature to occasionally get distracted during these tests: The phone rings, someone enters the office, some disaster strikes, and undoing the change is forgotten. This possibility is a good reason to not make changes in this manner, but of course it's difficult to resist taking a "short cut." One can adopt some methods to make these sorts of quick changes less likely to cause a long-term problem. If I plan to make a temporary change, I always copy /etc/mail/sendmail.cf to /etc/mail/sendmail.cf.REAL before making the edit. Then, if I forget, I'll see the .REAL file the next time I attempt to manipulate it and remember to either undo the change or update the M4 file before I do any further damage. I find this technique represents a reasonable compromise between discipline and expediency.

Someone who is interested in more information about the M4 language itself would be well advised to read the paper written on this language available in the 4.4 BSD Programmer's Supplementary Documents [KR94].