There are a handful of e-mail terms that we should cover. Let's start with:

sendmail.cf - This is the main configuration file for Sendmail.

MUA or Mail User Agent - These are programs that are used to read and write messages. We normally call these mail clients. Sendmail can be used as an MUA. Although Sendmail can be used as an MUA you're better off using something else. Most people prefer to use a full-featured e-mail client.

MTA or Mail Transfer Agent - These are programs that are used to route messages between users. The user's can be on the same machine or on different machines. If the users are on different machines then it's the job of the MTA to route the message to the other machine. Sendmail is an MTA.

MSP or Message Submission Program - These are programs that are allowed to modify message so that it meets e-mail specifications. An e-mail message can be said to have two distinct parts to it. The first parts are the message headers. Those parts of an e-mail message that are used to route the message between users are generally referred to as header information. Your mail client can usually be configured to display header information if you desire. By default this is generally disabled. There is a lot of information in the header section of an e-mail message. The second half of a message is generally referred to as the "body" of the message. This is the text that you typed. Whatever you're trying to convey to the other person can be thought of as the message body.

In the old days one Sendmail daemon did everything. It can be used to write the message and then it can check to make sure that the message that you typed meets specifications, and then it routes the message, and if you mailed it to a user on the same machine, it can then deliver the mail. There are now two Sendmail daemons. One daemon is used to strictly route the e-mail message. The other daemon is used to accept the message from the MUA and then it checks to insure that the message meets specifications.

An MSP could do things like ensure that all e-mail messages have today's date somewhere in the message body. A web page on this site will list out the specific duties of an MSP.

Sendmail also works with what it terms, "envelope" information. This works the same way as it does in the physical world. In the physical world you would write a letter, stuff it into an envelope, and then add the sender and receiver to the envelope, affix a stamp and drop it into the mail. The contents of the letter in the physical world, or in the electronic world, are not visible to the post office. In the electronic world e-mail can be accepted or rejected based solely on envelope information. It is not always necessary to send the message headers and body to the remote machine.

Let's use an example to help clear this up. In your e-mail client you generally tell the client your name and e-mail address before you start using the mail client software. This information becomes the sender information for any e-mail message that you write. When you click on "compose" or the equivalent option for your software, you fill in the "To:", "cc:", or "bcc:" fields to let the software know who the intended recipients are for your message.

Let's say you want to send the same message to a friend of yours who has an Internet mail account and to yourself as a reminder for whatever reason. You now have four pieces of envelope information. You have the sender for each envelope which in both cases is you, and two recipients, a user on some other e-mail system, and yourself. This is where e-mail works just like physical mail. Just as you would address two separate envelopes, Sendmail creates two different envelopes. On the first envelope, it lists you as the sender and your friend's e-mail account as the recipient. On the second envelope it lists you as the sender and you as the recipient. It then sends each message individually to the intended recipient. You didn't write two separate messages and address them to the recipients independently, but when Sendmail goes to send the message out, that is in essence what happens. You can see this for yourself if you use the mailq command to examine the contents of the mail queue. Each message will be listed separately.

When Sendmail connects to the e-mail server that holds your friend's account it will send their MTA the envelope information before it sends the message. Remember that the message consists of the header information and the message body. At this point, only the sender's and the recipient's e-mail addresses are being transferred between the two MTA's. The other MTA will then decide to accept or reject the message based solely on envelope information. Suppose you sent an e-mail to an address that does not exist. The other mail system doesn't need to receive the whole message just to figure out that it isn't going to deliver the message. It could simple look at the recipient's address and decide to accept or reject the message based on just that piece of information. Similarly if the other e-mail server thinks you send unsolicited commercial e-mail to its system, it could look at the sender information and decide that it will not accept any messages from your e-mail account. Again, the message contents do not need to be transmitted in this situation.

Once the other MTA decides that it will accept the e-mail message then it will ask the other MTA to go ahead and send the message headers and the message body. Then the other MTA will either deliver the mail or possibly send it on to yet another MTA.

Mailbox - A mailbox is a file that is the final destination for an e-mail message. The name of the mailbox can be the user name or the identity of a specific function, such as the postmaster. Mailboxes are stored in the /var/mail/username file which can exist either on the user's local system or on a remote mail server. In either instance, the mailbox is on the system to which the mail is delivered.

Let's take a quick look at how Sendmail routes e-mail in a TCP/IP environment. Sendmail, like web sites, uses either a hosts file or DNS to resolve a domain name to a TCP/IP address. For the purposes of these web pages if sendmail cannot resolve the hostname or domain name to a TCP/IP address the message will not be delivered.

You could in theory use just a hosts file if you're only going to deliver mail to an internal network. Then you would just address your messages to user@host. Just ensure that every host has a listing of all the other hosts in their respective /etc/hosts file and you're all set.

When your sending mail to a domain name or a sub domain name instead of a hostname, Sendmail will query a DNS server for the mail exchange records for that domain or sub domain and then will send the messages to the machine designated by the mail exchange records. In DNS, mail exchange records are referenced by the letters mx. Mail Exchange records lists the machines for the domain that will accept e-mail on behalf of the domain.

Sendmail uses macros and classes. Macros can be used to hold a single value. Classes are used to hold multiple values. There are a few classes that you need to be aware of. I'll list a few here and more later on when we discuss rule sets. Knowing what these macros do will aid you when you read through the rest of these web pages.

The macros $j, and $m are set to the identity of this host. $j is set to the fully qualified host name and $m is set to the domain part of the name (everything after the first dot). The class w contains the list of domains that the host will accept mail for. If the domain is not listed, then any mail sent for that domain to this host machine will be rejected. You use $=w in conjunction with DNS MX records. If a DNS mail exchange record points to this machine as being the machine that will receive messages for a certain domain then the designated machine will need to have that domain name added to class w. Failing to due so will result in e-mail messages that end up being bounced back to the sender. The easiest way to ensure that these macros and classes are configured properly is to set a fully qualified host name in the /etc/hosts file for each host in your environment.

By using class w, you can enable a machine to accept mail for many different domains. This could be important to you if you're doing domain hosting for other companies.

At the heart of the sendmail.cf file are the sequences of rules that rewrite mail addresses from one form to another. Because rewriting can require several steps, rules are organized into rule sets. Rule Sets make up the bulk of the sendmail.cf file.

The last thing we'll cover on terminology is the message queue. Before e-mail delivery is attempted Sendmail writes the message to the server's physical hard drive.

If you're writing a lengthy e-mail message addressed to a large group of users, what would happen to that message if the server crashed before it could send the mail out to all the recipients? You'd probably end up retyping the whole thing all over again.

The purpose of the queue is to handle things that are unforeseen. If the mail server for one of your recipients is offline their message can sit in the queue while Sendmail deals with the rest of the e-mails waiting to be sent. After a specified timeout, Sendmail will try to send the message again. It will keep doing this until another timeout that you set tells it to give up and stop trying to send the message or the message is delivered.

Next Section: Sendmail as an MUA - 3 of 32