لطفا منتظر باشید ...
Sendmail Configuration
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.
Table 19-1: Selected Sendmail Configuration Files
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.
/etc/mail/virtusertable
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
# service sendmail restart
Shutting down sendmail: [ OK ]
Shutting down sm-client: [ OK ]
/etc/aliases
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-owne r.
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
