|
|
Setting up a new installation of Sendmail used to be a daunting task. While it is an intricate and challenging program and most people don't want to devote their lives to mining its depths, it has become much more user friendly in the past 4 or 5 years. Luckily, you can now get Sendmail to do what you need with a minimum of fuss, leaving the more complex questions to your copious spare time.
| Tip |
Those who run Sendmail should have handy a copy of Sendmail by Bryan Costales and Eric Allman (3rd edition, O'Reilly and Associates, 2002). It contains Everything you need to know about running this MTA-and then some. |
There are a few files that Sendmail administrators work with frequently. Some configuration files need to be edited before Sendmail runs properly, while you'll work with others on a regular basis. Sendmail log files are filled with useful information, and are a good resource for initial troubleshooting. Table 19-1 shows a list of these files with a brief description of each.
|
Configuration Files |
|
|---|---|
|
/etc/aliases |
The OS aliases file that connects local recipient accounts to other local or nonlocal accounts (root, postmaster, tom@yahoo.com, and so on). It also allows you to set up group-mail recipients, as well as route incoming e-mail to scripts and commands on the system |
|
/etc/mail/sendmail.cf |
The file that Sendmail uses (generated from the mc file) for all of its runtime settings. Do not edit this file |
|
/etc/mail/sendmail.mc |
The main human-editable macro config file that is m4-processed down to create the runtime .cf file. Also found in the /etc/mail/ directory in newer installs |
|
/etc/mail/ |
Directory where most Sendmail individual settings files reside |
|
/etc/mail/access |
The setting file that is used to control e-mail flow to and through your server. Less common since SMTP-Auth has been implemented, but still used for some spam blocking or manually blacklisting people, domains, or IP address blocks |
|
/etc/mail/virtusertable |
This is the file that gives you control of domain-specific aliasing or virtual hosting of e-mail. For example, sending incoming mail for sales@mydomain.com to bob@mydomain.com, or creating catch-all e-mail addresses for entire domains |
|
/etc//mail/domaintable |
Includes a "domain table" that can be used to provide domain name mapping. Use of this should really be limited to your own domains. It may be useful if you change names (for example, your company changes names from oldname.com to newname.com) |
|
/etc/mail/genericstable |
This feature will cause certain addresses to be masqueraded or made to appear as another address |
|
/etc/mail/mailertable |
Can be used to override routing or provide DNS type routing for specific domains/ports. Used iwhen setting up a mail relay or mail hub for your domain(s) |
|
Log Files |
|
|---|---|
|
/var/log/mailog |
The mail log file where SMTP, POP, and other runtime related Sendmail messages are logged. Look here first when you're having problems working with runtime related errors |
|
/var/log/messages |
Standard service related issues, authentication messages, service start errors, and so on |
|
User/System Directories |
|
|---|---|
|
/var/spool/mail/ |
Where users' e-mail spool files are stored |
|
/var/spool/mqueue/ |
Where queued e-mail is stored |
| Note |
The term virtual hosting describes the act of hosting more than one domain or host on a single server or IP address. With a single host and a single IP address, you could potentially host hundreds of domains or fully qualified domain names (FQDNs). In an e-mail context, this is usually called vhosting. When speaking of web servers, this is called name-based hosting and is supported under the HTTPv1.1 protocol. |
The files in /etc/mail/ are critical for the Sendmail MTA. In a running domain, the most common file you'll edit is the /etc/mail/virtusertable file, as you'll see in the next section. If you need to block spammers and the like on a regular basis, /etc/mail/access may be your next most commonly edited file. The sendmail.mc file is used when you need to make MTA-wide changes to Sendmail, so be careful when editing this file-changes to the sendmail.mc file must be processed down to the sendmail.cf file using the m4 macro compiler. We'll make some basic changes to the sendmail.mc/cf pair in the Turning on Public IP SMTP Bindings section.
Though Sendmail is a complex program that uses many configuration files, most administrators work with a small selection of those files on a regular basis and leave the rest alone. Of the many Sendmail configuration files, /etc/mail/virtusertable is the one you'll probably work with most frequently as an e-mail administrator. This file controls virtual hosting, domain-specific, and user-based aliasing. Here's a sample virtusertable file:
[...] hire-me@mydomain.com bsmith@mydomain.com ## - -Local alias bob@mydomain.com bsmith ##--Local Junk mail accounts for Bob bsmithjunk@mydomain.com bsmith bsmithjunk1@mydomain.com bsmith ##--Local to Remote redirects billmary@mydomain.com wsmithok@earthlink.net bill-n-mary@mydomain.com wsmithok@earthlink.net butch-n-mert@mydomain.com wsmithok@earthlink.net ## -Multi-Domain Conflicting vhost addresses sales@mydomain.com bsmith sales@yourdomain.com mwalker sales@homestarrunner.com strongbad@aol.com ##-----Catch All Accounts----- @mydomain.com postmaster
Each section contains two columns. The first column contains the incoming address or address fragment that the MTA will actually see on incoming e-mail traffic, while the second column contains the actual local or remote address that should receive those messages.
Note that each section in the sample begins with a commented-out line describing the type of redirects in that section. Though your virtusertable file may be short, this is a good practice; the more traffic you get and the more redirects you manage, the harder it will be to find a problem in a virtusertable file without a roadmap.
| Note |
Catch-all accounts allow you to catch all unknown user (or undefined virtual user) e-mail and send it to one recipient-usually the domain administrator. The last line of the /etc/mail/virtusertable file shows a catch-all account. There are two important points to remember about these accounts. First, catch-all-accounts must appear below all other valid entries for that given domain. Second, if you enable a catch-all account for a given domain, all new e-mail addresses for that domain must now be placed in the virtusertable file in order for users to get their e-mail. Otherwise, a domain catch-all account will suck up all the e-mail going to users not defined in virtusertable. |
If you edit /etc/mail/virtusertable, you will need to rebuild the binary database files that the running Sendmail MTA uses before the edits can take effect. There are two easy ways to do this:
# cd /etc/mail # make
or (under Red Hat or Fedora-based Linux systems) simply restart the Sendmail service with
The /etc/aliases file is a standard system file that maps incoming e-mail aliases to local or remote system accounts. One of the first jobs on a new system is usually to ensure that the root alias points to an actual e-mail address, whether local or remote. Other important aliases include postmaster, help, and abuse.
A sample /etc/aliases file might look like this:
[...] # Person who should get root's mail #root: marc root: admin postmaster: root mailman: admin mailman-owner: mailman # Shared addresses webmaster: admin, mike, mike@yahoo.com helpdesk: bob, mike, mike@yahoo.com ## xcssa mailman mail-list ## created: 04-Jun-2001 root xcssa: "| /usr/share/mailman/mail/wrapper post xcssa" xcssa-admin: "| /usr/share/mailman/mail/wrapper mailowner xcssa" xcssa-request "| /usr/share/mailman/mail/wrapper mailcmd xcssa" xcssa-owner: xcssa-admin
Note that some of the aliases are mapped to other aliases, such as postmaster to root. In fact, the only actual person in the first section is admin, who ultimately receives all mail sent to root, postmaster, mailman, and mailman-owner.
As in most Linux config files, lines that start with a # are comments. It's a good idea to keep config files like this well-commented for clarity.
| Note |
This file also includes other aliases, such as one for a mailing list called xcssa. The xcssa alias resolves to mailman list-server wrapper scripts, a useful trick but one that can be very dangerous. Such a function could be set up to accept an e-mail that triggers a local binary, such as the address reboot@example.net used to trigger the binary /sbin/reboot (see man smrsh for more details). Be careful when associating aliases with scripts or programs lest you leave back doors open, and future problems. |
If you make changes to /etc/aliases, you will need to let Sendmail know that new aliases are available. You can do this with a simple command:
# newaliases
You must run this command to convert the human-readable /etc/aliases file into the binary format that the Sendmail MTA uses during runtime (/etc/aliases.db as a rule).
You can also use the sendmail command to enable /etc/aliases changes:
# sendmail -bi
|
|