I've removed advertising from most of this site and will eventually clean up the few pages where it remains.
While not terribly expensive to maintain, this does cost me something. If I don't get enough donations to cover that expense, I will be shutting the site down in early 2020.
If you found something useful today, please consider a small donation.
Sendmail can be a little scary. If the 1,000+ page O'Reilly reference doesn't give you pause, the cryptic configuration files probably will. But actually, if you can put up with a little pain to get by the basics, Sendmail really isn't all that difficult. It is complicated, but a few "rules of the road" will allow you to understand it.
First, let's clear up some possible misconceptions. Sendmail is a Mail Transport Agent (MTA), not a Mail User Agent (MUA). An MUA is what you typically use to read and compose mail- like "mail" or Netscape or Eudora or "pine". Sendmail is the behind the scene work horse that reads and acts upon alias files, .forward files and its own configuration files to decide how (and where) to deliver mail. You don't (generally) use Sendmail directly. Your MUA is the one who will pass mail to Sendmail for disposition.
There are other MTA's: qmail, smail and many, many more. Sendmail is just the most common.
Sendmail isn't POP or IMAP either. You may get your mail from a POP or IMAP server: that's a totally separate program that has nothing to do with Sendmail. Sendmail just delivers the mail, and (as we'll see later) it doesn't even really do the final part of that by itself; it will call upon other programs (like /bin/mail) to do the actual work of writing files. Sendmail's job is to transport the mail.
If that's all it does, why is the configuration file such a complex mess?
Well, part of the answer is that it's harder than it looks. Mail addresses come in many different formats, and Sendmail has to understand all of them. Sendmail has to understand alias files, and user's .forward files. It has to figure out what other machines are allowed to talk to it and what are not. It has to know how it is going to deliver mail that belongs to other machines. These details and more are all spelled out in the configuration file.
Another thing that complicates configuration files is the need to understand other mailing systems. If you were only using Sendmail within your local network of Unix or Linux machines, the Sendmail configuration file could be very simple. If you could further force your users to only use one standard for addresses (for example, never include a host name and never include extraneous comments), the configuration would be even more simple. Unfortunately, the real world is more complex, and therefore so is the typical Sendmail configuration.
The actual configuration file that Sendmail reads is probably going to be be "/etc/sendmail.cf". Technically it doesn't have to be that, but it's rare (other than when testing) for it not to be. On many systems now, /etc/sendmail.cf will be a link pointing to /etc/mail/sendmail.cf but you aren't likely to find any other variance. That is the actual configuration file, but many sites configure sendmail without ever looking at that file by using "m4". That's a macro processor that can read and act upon macro definition files that will produce a sendmail.cf file. Using these macros is a bit easier than writing your own configuration files, but it's still rather obscure for the uninitiated. I'll talk about m4 macros later, but for now we're going to dive right into the real stuff.
OK, take a deep breath and trust me: this isn't as bad as it looks.
The sendmail configuration file consists mostly of definitions and rules. Every line in the file starts with a letter that tells you what you are looking at. For example, every rule begins with a "R". Here's a few rules:
Looks pretty awful, doesn't it? Don't panic yet, it is not as bad as it seems. For now, just accept that those rules tell Sendmail how to do something.
The main functions of rules are to validate addresses and to select a delivery agent. Rules may also rewrite addresses either for internal convenience or because that's what you want: you may want mail from "[email protected]" to appear to come from "[email protected], for example.
Don't worry for now about HOW the rules work. For now, just accept that they rewrite addresses and help make decisions. How they do that is unimportant right now.
To accomplish these things in a sensible manner, rules are divided into "sets". There may be dozens of rule sets in your configuration file, but it's very easy to follow the flow because there is always a specific starting point and Sendmail will always follow a particular path through the sets. Before we get to that, though, you need to be able to recognize a rule set.
This used to be easy. Rule sets start with an "S" and were followed by a number. So you'd just see:
Well, rule sets still can be written that way, and they still do start with an "S", but now they can also be words rather than just numbers. Here are a few of the rule sets from my sendmail.cf:
Notice that some of them have an "=" followed by a number? There's a reason for that. Sendmail internally identifies all rule sets by number, and certain numbers are "special". For example, all addresses (both sender and recipients) first pass through rule set 3. That's "canonify" above, and the "=3" tells Sendmail where to find rule set 3. Sendmail doesn't work in order through the configuration file; it will always start with rule set 3 no matter where in the file that is located.
Most of what S3 (the shorthand way of referring to it) does is put addresses in a convenient form for the other rules to work with. Because of the many different forms of mail that have existed, S3 can be pretty complex. On my machine, 55 lines of rules comprise S3 (counting a sub routine rule that it can call).
Remember, for the moment we don't care about the details of S3 or any other set. Here we are taking a bird's eye view of the overall process, and that process starts by running S3 for the sender address and each recipient.
The next thing Sendmail does is call S0 to select a "delivery agent". This figures out where the mail is going: should it be handed over to /bin/mail for local delivery, or will it be delivered directly to the host it is addressed to? If it is directed to a local user, does their .forward file cause the mail to go somewhere else? Perhaps the address is an alias? Maybe it needs to be handed to a UUCP gateway (rather rare nowadays, but still possible).
The S0 rule also makes another selection. In addition to the delivery agent, it also selects two rule sets that will be used later on. We'll get into the details of that later, but for the moment, here's an "M" (delivery agent) line from my file:
Just notice the S= and R= part of this for the moment. These are the rule sets that will be used if the "local" delivery agent has been selected.
Also note that "procmail" will be what actually delivers the message. Sendmail itself only accepts and sends mail; it's not responsible for much else. It doesn't provide Pop or Imap either.
After running S0, Sendmail runs other rules. The sender's address is run through S1, and then through whichever "sender" rule set was selected by S0. Recipient addresses are sent through S2, and then through whichever "recipient" rule was selected by S0. Finally, both sender and recipient addresses are put through S4. The purpose of S4 is just to undo any convenience or special marking rewriting that was done by S3. For example, S3 might rewrite a uucp style address to what looks like a standard mail address, but mark it as "uucp". Set S4 needs to undo that work so that uucp (which will have been selected as the delivery agent) can see the address in a format it understands.
As any rule can call another rule set, there can be lots more rules than these basic sets, but the flow always works this way.
If you looked closely at a real .cf file, you may have noticed that both the S= and R= from the delivery agent actually seem to refer to two separate rule sets
That's true: S= refers to both EnvFromL and HrdrFromL. This is to allow different processing of header lines and the envelope. The distinction here is this: the envelope is information that has to do with delivery. Envelope information is passed to other programs, for example to tell them who to deliver to. It isn't part of the mail itself. While a header line might show multiple recipients, a delivery program might only be told about one of them (because the other recipients belong to other delivery agents). Thus the (possible) need for different rule sets to process each part.
That's actually the simple part. Rules are very easy, and Sendmail conveniently provides a nice way to test rules to see exactly what they do. Understanding WHY a rule has to do what it does may lie buried in the mists of some long forgotten mail system, but the way the rules work is pretty straightforward.
Some overall concepts first:
Each rule consists of a Left Hand Side (LHS) and a Right Hand Side (RHS) separated by tabs. An optional comment (tab separated again) may follow the RHS.
The LHS is the pattern matching side. If the address being examined matches the LHS, it will be transformed by the RHS.
Rules are re-read and re-executed if the LHS again matches what the RHS produced. In other words, rules are recursive to themselves. The two exceptions to this are if you see $: or [email protected] at the BEGINNING of the RHS of the rule. It's possible to write a rule that would get stuck forever, looping back upon itself. Sendmail will recognize simple cases like this and stop the recursion, but it can be fooled by complex situations.
The $: at the beginning of the RHS stops the recursion after one pass. [email protected] makes one pass, but then does not execute any more rules in the set.
Unless you see [email protected] at the beginning of the RHS, Sendmail falls through to the next rule whenever the LHS no longer matches the address it is working on. That next rule will see that address AS REWRITTEN by the previous rule.
The RHS only executes (and [email protected] only returns) if the LHS matches.
Great. What's a token and what's a class?
A token is part of an address. All addresses are broken into tokens: [email protected] becomes the 5 tokens:
A class is a list of words that could match (or not match) tokens. We'll come back to that later; let's work with the simple stuff first.
How could we match an address like "[email protected]"? This LHS would match:
and so would this:
Let's look more closely at certain rule sets.
This is the part of S3 that removes angle brackets, for example from "Fred Thompson <[email protected]>". Notice that the first and last of these have the "$:" at the beginning of the RHS; these rules will execute only once.
Now for the fun part. We're going to have Sendmail itself show us just how these rules work. (If you are not root, you probably can still do this). First, put these lines into /tmp/testrules:
And then run:
You may need to specify a specific path to sendmail like "/usr/sbin/sendmail" if you are not root.
You should get something like this:
If you want to play with more addresses, just do:
You can then enter "3" followed by addresses until you get tired of it.
If you leave of the "-d21.12" you can still test rules; you just don't get the details of each line.
Let's look at these rules again:
The first rule is going to match anything and put brackets around it. The $1 on the RHS matches the first (and only) token that matched on the LHS. (token matching runs left to right).
That's how our input got rewritten as < Fred Thompson < [email protected] . com > >
This rule needs $: to keep from getting stuck continually adding brackets. Remember that the next rule sees the rewritten result.
Next, we match one or more tokens followed by a left bracket, followed by any number of tokens and a right bracket. Our new input matches, so it again gets rewritten, this time picking the second token to match. It now looks like this: < [email protected] . com > >
That gets rerun through the rule again (no $: or [email protected] to stop it) but this time it fails.
This strips off the excess > , tries itself again, and then fails.
This rule doesn't match. If it did, we'd return immediately ([email protected]).
Finally, this cleans off the remaining brackets and leaves us with a simple address. Why all the extra fuss to do this? Because an address like this is legal:
Try that against /tmp/ruleset
One other thing you need to know when looking at rules sets. Sendmail can define macros. For example,
defines a macro called "A". That macro can be used in a LHS (it's unusual to do so, but it could be done). If it were used, you might miscount the $1, $2 replacement characters on the RHS thinking that this would be part of them. For example (and a nonsensical and artificial example indeed):
That would NOT be replaced with ":include:". It would be replaced with the next token that matched the $- ; $2 would be the $* match.
If that makes your head hurt, don't worry too much- you are very unlikely to see anything like that on the LHS.
Armed with this knowledge, you can now examine your real configuration file. Just use "sendmail -bt" or "sendmail -d21.12 bt" and play. You can list rules with "=S" followed by its number or its name. If you see "$>" in the RHS of a rule, that's calling another rule set; the number or name that follows is the set being called. You won't understand everything just from reading this, but this will get you started.
You will probably find at least one ".mc" file on your machine, and you may find dozens. M4 is a general purpose macro processor, and sendmail distributions generally provide an appropriate series of macros that can generate a working sendmail.cf file. All you have to do is pick an appropriate .mc file and run:
If you don't have the .mc file you need, you can probably find it on the Internet.
As the .mc files are generally at least somewhat commented, picking and editing an appropriate file isn't usually too difficult. There are some things that aren't obvious, though:
M4 macros generate blank lines even when they don't generate anything else. The dnl just stops unwanted blank lines.
Nothing for you to worry about; it's just a way to put things that belong together in the output without necessarily having them together in the .mc file.
Ah, that is the rub. These files are only a little bit less confusing than the .cf file itself. And it may seem that you only have one file to work with. For example, RedHat systems only put one sendmail.mc in /etc/mail.
However, you will probably find a line like this in that file:
If you look one directory up (/usr/share/sendmail-cf) from that, you'll find a very helpful README that explains everything very well and all the rest of the samples you might want to look at.
This should be enough to get you started. I really recommend the O'Reilly reference and Sendmail.org for deeper study. There is a newsgroup (comp.mail.sendmail) also.
If you found something useful today, please consider a small donation.
Got something to add? Send me email.
More Articles by Tony Lawrence © 2011-05-06 Tony Lawrence
Solving today's problems with yesterday's technology,someday (Kevin Brooks Clark)