Configuring sendmail


To configure the sendmail facility, you edit configuration files in /etc/mail and /etc that are then used to by the sendmail start-up script to generate database files. Those database files are, in turn, used by the sendmail daemon to control the behavior of your sendmail server. Once sendmail is configured, you can begin adding user accounts to have mailboxes on your server. The general steps I describe in this section for configuring sendmail are:

  1. Getting a domain name — You need a unique Internet domain name to assign to your mail server. You can purchase an Internet domain name from one of many different places, and then have DNS MX records for your domain point to the mail server you are creating.

  2. Configuring basic sendmail settings — In this step, you edit the /etc/mail/sendmail.mc file. That file defines such things as the locations of other configuration and log files, as well as letting you configure some behavior of the sendmail daemon.

  3. Defining outgoing mail access —The most critical security issue associated with your mail server is which mail messages it will accept to relay to other mail servers. By editing the /etc/mail/access file, you can indicate the hosts and users from which your server will accept mail for local delivery or relay.

  4. Configuring virtual servers — By default, sendmail assumes that you are setting up the mail server for the domain of which the server is a member. To have sendmail on a single computer be the mail server for multiple domains (referred to as virtual servers), you need to define each domain name in the /etc/mail/local-host-names file.

  5. Configuring virtual users — Using the /etc/mail/virtusertable configuration file, you can instruct the sendmail daemon what to do with the mail it receives for the users and domains it's configured to handle. This file give you a lot of flexibility to take mail addressed to a particular user and direct it to a particular mail box, forward it to a different mail address, or reject that mail in various ways.

  6. Adding user accounts — You need to add a user account for every user that has a mailbox on your mail server.

  7. Starting sendmail and generating database files. Starting sendmail runs the sendmail server daemon, but also compiles your configuration files into database files that can be used by sendmail. If the server is already running, you can simply compile the configuration files and have any new settings take effect without restarting the server.

The following subsections provide details on each of these steps.

Getting a domain name

For people to be able to send mail to the users on your mail server, you must have your own domain name. Chapter 25 describes how to get your own domain names and set up a DNS server. The critical issue for your mail server is to make sure that the MX record for your domain on the DNS server points to the address of your mail server.

Configuring basic sendmail settings (sendmail.mc)

Much of the configuration of your sendmail server comes from information in your /etc/mail/sendmail.mc file. Because this file sets sendmail default values that can be used in most cases, you may not have to do much with sendmail.mc. However, I recommend you step through this section so you understand how your mail server is configured.

Changes you make to the sendmail.mc file do not immediately take effect. First you must compile the sendmail.mc settings to generate the /etc/mail/sendmail.cf file. I describe how to do that in the "Starting sendmail and generating database files" section.

The resulting /etc/mail/sendmail.cf file contains over 1,700 lines of settings and comments that are used to direct the behavior of your sendmail daemon. The m4 macros you use in the sendmail.mc file are different from the resulting settings in the sendmail.cf file.

To find out which macros to use for a setting you find in the sendmail.cf file, refer to the /usr/share/doc/sendmail/README.cf file. If you are interested in details on the contents of your sendmail.cf file, I have included an exhaustive description of sendmail.cf at the Red Hat Linux Bible Web site: (www.wiley.com/go/fedora3bible).

Caution 

Because of the way sendmail is configured in Fedora, you should not directly modify the sendmail.cf file. The sendmail.cf file is regenerated automatically when sendmail restarts if sendmail.mc changes. As a result, any modifications made directly to sendmail.cf will be lost.

The following code samples are from the /etc/mail/sendmail.mc file that accompanies the Fedora version of sendmail.

Note 

Lines that begin with dnl (delete to new line) in the sendmail.mc file are comment lines. In most cases, I have left them out in the examples shown.

divert(-1)dnl  include(`/usr/share/sendmail-cf/m4/cf.m4')dnl VERSIONID(`setup for Red Hat Linux')dnl  OSTYPE(`linux')dnl  

The first few lines of the sendmail.mc file do some housekeeping. The divert line removes extra output when the configuration file is generated. The include line causes rule sets needed by sendmail to be included. The VERSIONID line identifies the configuration file as being for Red Hat Linux systems, such as Fedora (though this setting is not checked, so it could be anything you like). The OSTYPE, however, must be set to linux to get the proper location of files needed by sendmail.

dnl define(`SMART_HOST',`smtp.your.provider')  

By default, the sendmail daemon tries to send your outgoing e-mails directly to the mail server to which they are addressed. If you want all e-mail to be relayed through a particular mail server instead, you can remove the comment (dnl, which stands for "delete to new line") from the SMART_HOST line above. Then, change smtp.your.provider to the fully qualified domain name of the mail server you want to use. Of course, you need to be sure that the SMART HOST you define will accept relays from your mail server.

define(`confDEF_USER_ID',``8:12'')dnl 

Instead of running as the root user, the daemon runs as the mail user (UID 8) and mail group (GID 12), based on the confDEF_USER_ID line set previously. This is a good policy, since it prevents someone who might compromise your mail server from gaining root access to your machine.

dnl define(`confAUTO_REBUILD')dnl  define(`confTO_CONNECT', `1m')dnl  

If you remove dnl, the confAUTO_REBUILD line will tell sendmail to automatically rebuild the aliases database, if necessary. The confTO_CONNECT line sets the time sendmail will wait for an initial connection to complete to one minute (1m).

define(`confTRY_NULL_MX_LIST',true)dnl  define(`confDONT_PROBE_INTERFACES',true)dnl  

With confTRY_NULL_MX_LIST true, if a receiving server is the best mail exchange (MX) for a host, try connecting to that host directly. If confDONT_PROBE_INTERFACES is true, the sendmail daemon will not insert local network interfaces into the list of known equivalent addresses.

define(`PROCMAIL_MAILER_PATH',`/usr/bin/procmail')dnl  define(`ALIAS_FILE', `/etc/aliases')dnl  dnl define(`STATUS_FILE', `/var/log/mail/statistics')dnl  

The next three lines (PROCMAIL_MAILER_PATH, ALIAS_FILE, and STATUS_FILE) set locations for the program that distributes incoming mail (procmail, by default), the mail aliases file, and the mail statistics file, respectively.

define(`UUCP_MAILER_MAX', `2000000')dnl  define(`confUSERDB_SPEC', `/etc/mail/userdb.db')dnl  define(`confPRIVACY_FLAGS', `authwarnings,novrfy,noexpn,restrictqrun')dnl  define(`confAUTH_OPTIONS', `A')dnl  

The UUCP_MAILER_MAX line sets the maximum size (in bytes) for messages received by the UUCP mailer. The confUSERDB_SPEC line sets the location of the user database (where you can override the default mail server for specific users). The confPRIVACY_FLAGS line causes sendmail to insist on certain mail protocols. For example, authwarnings causes X- Authentication-Warning headers to be used and noted in log files. The novrfy and noexpn settings prevent those services from being requested. The restrictqrun option prevents the -q option to sendmail.

dnl define(`confAUTH_OPTIONS', `A p')dnl  dnl TRUST_AUTH_MECH(`EXTERNAL DIGEST-MD5 CRAM-MD5 LOGIN PLAIN')dnl  dnl define(`confAUTH_MECHANISMS', `EXTERNAL GSSAPI DIGEST-MD5 CRAM-MD5         LOGIN PLAIN')dnl  dnl define(`confCACERT_PATH',`/usr/share/ssl/certs')  dnl define(`confCACERT',`/usr/share/ssl/certs/ca-bundle.crt')  dnl define(`confSERVER_CERT',`/usr/share/ssl/certs/sendmail.pem')  dnl define(`confSERVER_KEY',`/usr/share/ssl/certs/sendmail.pem')  dnl define(`confDONT_BLAME_SENDMAIL',`groupreadablekeyfile')dnl  

Some of the group of lines just shown that begin with dnl (so they are commented out) can be uncommented (remove the initial dnl) to provide certain features. Others are set explicitly. The confAUTH_OPTIONS line can be used to set options used with SMTP authentication. This example (with A and p options) would allow authenticated users with plain text logins to send mail. The TRUST_AUTH_MECH line would cause sendmail to allow authentication mechanisms other than plain passwords (if dnl were removed). The confAUTH_MECHANISMS line can configure the types of authentication mechanisms that can be used (if dnl were removed). The next few lines above set the location of the certificates directory for sendmail to /usr/share/ssl/certs, then identify different files in that directory that hold the certificates and keys needed for authentication. The confDONT_BLAME_SENDMAIL line should be uncommented if the key file needs to be readable by applications other than sendmail. (Normally, you would not want the file to be readable by everyone.)

dnl define(`confTO_QUEUEWARN', `4h')dnl  dnl define(`confTO_QUEUERETURN', `5d')dnl  dnl define(`confQUEUE_LA', `12')dnl  dnl define(`confREFUSE_LA', `18')dnl  define(`confTO_IDENT', `0')dnl  

The commented lines above actually show the default values set for certain timeout conditions. You can remove comments and change these values if you like. The confTO_QUEUEWARN option sets how long after delivery of a message has been deferred to send a warning message to the sender. Four hours (4h) is the default. The confTO_QUEUERETURN option sets how long before an undeliverable message is returned. The confQUEUE_LA and confREFUSE_LA options set the system load average levels at which mail received is queued or refused, respectively. The confTO_IDENT option sets the timeout when waiting for a response to an IDENT query to be received (by default it is 0, which means no timeout).

FEATURE(`no_default_msa',`dnl')dnl  FEATURE(`smrsh',`/usr/sbin/smrsh')dnl  FEATURE(`mailertable',`hash -o /etc/mail/mailertable.db')dnl  FEATURE(`virtusertable',`hash -o /etc/mail/virtusertable.db')dnl  FEATURE(redirect)dnl  FEATURE(always_add_domain)dnl  FEATURE(use_cw_file)dnl  FEATURE(use_ct_file)dnl  FEATURE(local_procmail,`',`procmail -t -Y -a $h -d $u')dnl  FEATURE(`access_db',`hash -T<TMPF> -o /etc/mail/access.db')dnl  FEATURE(`blacklist_recipients')dnl  

The FEATURE macro is used to set some special sendmail features. The no_default_msa feature tells sendmail not to generate a default MSA daemon (which normally is set to listen on port 587). The smrsh feature defines /usr/sbin/smrsh as the simple shell used by sendmail to receive commands. The mailertable and virtusertable options set the locations of the mailertable and virtusertable databases. The redirect option allows you to reject mail for users who have moved and provide new addresses. The always_add_domain option causes the local domain name to be added to the host name on all delivered mail. The use_cw_file and use_ct_file options tell sendmail to use the file /etc/mail/local-host-names for alternative host names for this mail server and /etc/mail/trusted-users for trusted user names, respectively. (A trusted user can send mail as another user without resulting in a warning message.)

The local_procmail option sets the command used to deliver local mail (procmail), as well as options to that command (including the $h hostname and $u user name). The access_db option sets the location of the access database, which identifies which hosts and users are allowed to relay mail through the server. The blacklist_recipients option turns on the ability of the server to block incoming mail for selected users, hosts, or addresses. (The access_db and blacklist_recipients features are useful for blocking spam.)

EXPOSED_USER(`root')dnl  DAEMON_OPTIONS(`Port=smtp,Addr=127.0.0.1, Name=MTA')dnl  

The EXPOSED_USER line allows the root user name to be displayed instead of a masquerade name. As it stands, the DAEMON_OPTIONS line allows only incoming mail created by the local host to be accepted. Be sure to comment this line out if you want to allow incoming mail from the Internet or other network interface (such as the local LAN).

FEATURE(`accept_unresolvable_domains')dnl 

The accept_unresolvable_domains option is on, causing you to accept mail from host computers that don’t have resolvable domain names. If you have client computers (such as dial-up computers) that need to use your mail server, leave this option on. Turning it off, however, can help eliminate spam.

LOCAL_DOMAIN(`localhost.localdomain')dnl  MAILER(smtp)dnl  MAILER(procmail)dnl  

The LOCAL_DOMAIN option here causes the name localhost.localdomain to be accepted as a name for your local computer. The last lines in your sendmail.mc file define the mailers to use on your server. The /usr/share/sendmail-cf/mailer directory contains definitions for smtp, procmail, and other mailers. After you have made the changes you want to the sendmail.mc file, you can regenerate the sendmail.cf file as described in the "Starting sendmail and generating database files" section.

Defining outgoing mail access

Every time an e-mail message intended for outgoing mail is received by your sendmail server, the server needs to decide if it will accept or reject relaying of that message. Policies that are too restrictive might prevent legitimate mail from getting out. Policies that are too loose can leave your server open to spammers.

With e-mail abuse the way it is these days, you cannot run an open relay (where your server simply relays all messages it receives to the requested mail servers). Spammers can use software referred to as spiders to look for open relays. If you leave your mail server open, they will find you quickly and use your machine to relay their spam. The result of a spammer using your machine can be:

  • You could end up on blacklists. Some e-mail blacklist maintainers look for open relays themselves and block them before abuse is even reported. Servers that use those blacklists will block all mail from you, even legitimate e-mail.

  • People will hate you. Your mail server will be identified as the one sending the spam. As a result, people may retaliate against your server, or at the very least really wish you would stop sending them ads to help them get out of debt or enhance themselves in some way.

This section describes how to set up the sendmail access file (/etc/mail/access) to include a sensible set of rules defining for whom your server will relay mail. Using the access file, sendmail can make decisions about whether or not to relay a message based on the sender's host/domain name, IP address, or e-mail address. You can further refine the match by checking for those addresses in Connect, From, or To data associated with the message.

There are then four basic actions you can have the server take on a match:

  • RELAY — Your mail server could simply send the message on to the mail server requested in the mail message.

  • REJECT — The message is rejected (not relayed) and the sender is told it was rejected.

  • DISCARD — The message is silently discarded and the sender is not told.

  • ERROR: text you choose — You can add some informative text here, to give the sender some reason why the relay did not occur.

The /etc/mail/access file, by default, only relays messages from users who are directly logged into the mail server (localhost). Without being explicitly allowed, users from all other machines are not allowed to relay messages. Here's how the access file is set up by default:

localhost.localdomain     RELAY  localhost                 RELAY  127.0.0.1                 RELAY 

With these defaults set, only mail sent from the local machine is relayed. So, if the only outgoing mail you send is done while you are logged in directly to the server, you don't need to change this file. The following examples illustrate how you can selectively choose to relay or reject mail received by your sendmail server:

Connect:192.168                  RELAY  Connect:linuxtoys.net            RELAY  Connect:spammer-domain.com       REJECT      From:chris@linuxtoys.net         RELAY  To:spidermaker.com               RELAY  To:former-user@linuxtoys.net     ERROR: User no longer works here 

On the Connect:192.168 line, the network address (presumably the first part of the IP addresses used on your LAN) is allowed to relay mail. This is a good way to allow everyone sending mail from a machine on the local LAN to have their mail relayed. On the next line (Connect:linuxtoys.net), essentially mail coming from any machine in the named domain is allowed to be relayed. The third line represents a domain that you know to be a spam relay, so you reject messages originating from that domain.

The next three lines indicate how to treat mail received for relaying, based on the From and To names associated with the message. As you can see, the first example allows relay of any messages from chris@linuxtoys.net. In the last example, mail being forwarded to a particular person (former-user@linuxtoys.net) is rejected and a custom error message (in this case "User no longer works here") is sent back to the sender.

Note 

Use some caution when you are creating relay rules based on user e-mail address. Because those values are reported by the users themselves, they are vulnerable to being spoofed.

Once you have adjusted this file to suit you, you must rebuild the access database (access.db file) for the changes to take effect. See "Starting sendmail and generating database files" for information on this topic.

Configuring virtual servers

If you have set up a sendmail mail server for one domain, it's quite possible that you will someday want to have multiple domains served from that same computer. To create virtual servers on the same computer, you must add the name of every domain being served to the /etc/mail/local-host-names file.

For example, if your sendmail server were handling e-mail accounts for linuxtoys.net, example.com and example.net domains, the local-host-names file would appear as follows:

# local-host-names - include all aliases for your machine here.  linuxtoys.net  example.com  example.net 

Even if you are only serving one domain with your mail server, it is a good idea to identify that domain in this file. When messages come to the server for the domains listed here, sendmail knows to try to deliver the messages locally. Messages for domains not listed here sendmail interprets as needing to be relayed.

Note 

If you want to off-load the processing of mail for a particular domain that is currently being directed to your sendmail server, you can use the /etc/mail/mailertable file. After setting up a DNS MX record to point to your sendmail server for this domain, and listing that domain name in the mailertable file, you can identify another computer that sendmail will forward all the traffic to for that domain. For example:

example.com smtp:mx1.linuxtoys.net 

This example shows that all messages destined for example.com that are received by your sendmail server are forwarded to the server named mx1.linuxtoys.net. The smtp indicates that the server supports Simple Mail Transfer Protocol.

Configuring virtual users

Incoming mail to your sendmail server will be directed to your machine with a request to deliver the message to a particular person at a particular domain name. For each domain that the sendmail server supports, you can identify how e-mail to mail recipients of that domain is treated.

With sendmail, you set up virtual user definitions in the /etc/mail/virtusertable file. Essentially, you are telling sendmail to redirect messages addressed to particular user names and/or domain names based on definitions you set up.

Configuring the virtusertable file is particularly important if your server is handling mail for multiple domains. That's because, by default, mail for the same user name (regardless of the domain name) will be stored in the same mailbox. For example, if your server handles mail for example.com and linuxtoys.net domains, mail for chris@example.com and chris@linuxtoys.net, would all be directed to /var/spool/mail/chris mailbox. With the virtusertable file, you can change that behavior in a lot of ways.

The virtusertable file is empty by default. The following are some examples that illustrate how incoming messages can be directed in different ways based on virtusertable definitions.

chris@linuxtoys.net       chris  cnegus@linuxtoys.net      chris  francois@linuxtoys.net    francois@spidermaker.com  info@linuxtoys.net        info-list  bogus@linuxtoys.net       error:nouser No such user here  @example.net              example-catchall  @example.com              %1@linuxtoys.net 

In the first two lines, incoming mail destined for chris or cnegus at linuxtoys.net is directed to the mailbox for the local mail server user named chris. In the next line, any e- mail directed to francois in the same domain goes to francois@spidermaker.com. After that, e-mail sent to the info user name is saved to the local info-list mail account.

The line beginning with bogus@linuxtoys.net illustrates an error condition. Here, e-mail destined for the user named bogus will be rejected with the error message No such user here being directed back to the sender. Besides creating custom error messages, you can also use any Enhanced Mail System Status codes that are compliant with RFC 1893.

The last two lines (beginning with @example.net and @example.com) illustrate how e- mail for all recipients for a given domain can all be directed to the same place. In the first case, all example.net messages go into the mailbox for the user named example-catchall. The last line shows how the users from a particular domain can all be mapped into their same user name (%1) on a selected domain name.

Once you have made changes to this file to suit you, you must rebuild the virtusertable database (virtusertable.db file) for the changes to take effect. See "Starting sendmail and generating database files" for information on this topic.

Adding user accounts

Ultimately the e-mail received by your mail server is placed in a user's mailbox, where the user can pick it up and read it at his or her leisure. Each of those user names must be added as as real users on your Fedora system. For example, to add the user chris to your Fedora sendmail server, you could type (as root user):

 # useradd -s /sbin/nologin chris 

This action creates a user account named chris in the /etc/passwd file, sets the shell to /sbin/nologin, and creates a mail box for that user in /var/spool/mail/chris. The /sbin/nologin shell prevents the user from logging in to a shell (which is a good security practice when you only want a user to have mail or FTP access, for example). Now, sendmail can direct e-mail to that user's mail box.

For that user to be able to access his e-mail later from his POP client, he will need a password for his user account. Set the password for that user with the passwd command as follows:

 # passwd chris Changing password for user chris  New UNIX password: ******** Retype new UNIX password: ******** passwd: all authentication tokens updated successfully  

Make sure that the user has this user account name and password so it can be configured into the user's e-mail client.

Starting sendmail and generating database files

None of the configuration that you just did to your sendmail.mc, virtusertable, access, domaintable, and mailertable configuration files take effect until they are regenerated into database (.db) files. There are a few different ways you can go about loading your configuration files into database files:

  • Restarting sendmail — Each time you reboot your computer or restart the sendmail daemon (service sendmail restart), all sendmail configuration files (including sendmail.mc)are compiled into database files that are ready to be used by the sendmail server. You can also just rebuild the databases without stopping the sendmail daemon (including the /etc/aliases.db file) using the sendmail startup script. To simply rebuild the database type:

     # /etc/init.d/sendmail reload 

    This command rebuilds all the database files, including the /etc/aliases file.

  • Making the configuration files — Using the make command, you can have some or all of the configuration files made into database files, so they become immediately usable by the sendmail daemon. To do that, change to the /etc/mail directory, then type either make all or make with the target database file you are creating. For example:

     # cd /etc/mail # make virtusertable.db 

    You can replace virtusertable.db with access.db, domaintable.db, mailertable.db, or sendmail.db. (Note that you use the .db target name and not the name of the original configuration file.) As mentioned, you can also use the make all command to rebuild all database file.

At this point, your sendmail server should be up and running. You can test your server by sending mail to it and checking log files to see how the server reacted. Make sure that your firewall allows requests on TCP port 25. Then check that your mail server is responding to requests by typing the following:

 # telnet localhost 25 Trying 127.0.0.1...  Connected to localhost.localdomain (127.0.0.1).  Escape character is '^]'.  220 toys.linuxtoys.net ESMTP Sendmail 8.12.11/8.12.11;   Sun, 23 May 2004 03:34:02-07--  

You can see that the sendmail daemon is running and responding to port number 25. Try typing HELO. When you are done, type QUIT to exit.

Note 

For more information on troubleshooting your mail server, refer to the Linux Troubleshooting Bible, from Wiley Publishing.

Redirecting mail

At times, your e-mail users may want to redirect mail to some place other than their own mailboxes on the local server. Each user can redirect his or her mail using the .forward file. System-wide, you as the administrator can set aliases to redirect mail in the /etc/aliases file.

The .forward file

One way for users to redirect their own mail is through the use of the .forward file, which users can place in their own home directories (for example, /home/jkpat/.forward). The format of a plain-text .forward file is a comma-separated list of mail recipients. Common uses of the .forward file include:

  • Piping mail to a program to filter the mailbox contents:

    "| /usr/bin/procmail" 
  • Sending mail destined for one user (for example, jkpat) to another (for example, cht09, on a different machine in this case):

    cht09@other.mybox.com 
  • Delivering mail to the local user (jkpat again) and sending it to two others (cht09 and brannigan):

    \jkpat, cht09@other.mybox.com, \brannigan 
    Tip 

    You are not allowed to have a .forward file in a directory that can be read by all users. If you leave permissions open on a .forward file, sendmail will ignore that file and not forward mail as youwant. To allow .forward files with open permissions to be used by sendmail, you can remove the dnl from the confDONT_BLAME_SENDMAIL line in the sendmail.mc file.

The aliases file

A more flexible method of handling mail delivery (system-wide rather than being specific to one particular user) involves the /etc/aliases file, which is also a plain-text file. The aliases file contains a name followed by a colon, and then a user name, another alias, a list of addresses, a file, or a program to which mail will be delivered. The name on the left side of the colon (which can be a valid user name or just an alias) can then be used as an e-mail recipient on the local machine or on a remote machine.

Some aliases are already set by default in /etc/aliases. For example, because there are a lot of administrative users defined in Fedora (bin, adm, lp, etc.), instead of having separate mailboxes for each one, messages for all of them are directed to the root user's mailbox as follows:

bin:           root  daemon:        root  adm:           root  lp:            root 

Using the aliases file for mail-aliasing allows for several extensions to normal mail-handling behavior:

  • You can use the aliases file yourself to create mini-mailing lists. Here's an example:

    info-list: chris, tweeks, francois@spidermaker.com 

    In this example, any messages sent to info-list are distributed to chris, tweeks, and francois@spidermaker.com. Notice that the user list can be a combination of local users and outside mail addresses.

  • One account can receive mail under several different names:

    patterson: jkpat 

    This indicates that any mail addressed to patterson@mybox.com (just an alias) will arrive in the mailbox of jkpat (an actual user account).

  • Mail can be received under a name that isn’t a valid (or reasonable) user name:

    Charlie.Jackson.II@mybox.com: jackson 

    He wouldn’t really want to type Charlie.Jackson.II as a user name, but that doesn’t mean he can’t receive mail as such.

  • Messages intended for one user can be redirected to another account (or to several accounts):

    oldemployee: bradford  consultant: bradford, jackson, patterson  users: :include:/root/mail/lists/users 

    Here, any message for oldemployee@mybox.com would be delivered to the mailbox of user bradford. Also, the users bradford, jackson, and patterson would receive any mail addressed to consultant. The third line indicates that the recipients of the “users” alias are specified in the file /root/mail/lists/users.

  • Mail can be sent directly to a file on the local machine:

    acsp-bugs: /dev/null  trouble-ticket: /var/spool/trouble/incoming  

    In the first line, because the fictional ACSP program is no longer used on the machine, there’s no need to track its errors, so the mail is effectively ignored. The second line stores incoming trouble tickets in the /var/spool/trouble/incoming file. Remember that if you enable this, anyone anywhere can send you a sufficiently large message to fill up the partition on which that directory resides. This is a security risk and should be carefully evaluated before being implemented.

When you are done adding new aliases, type the following to have those changes take effect:

 # newaliases 
Tip 

When resolving addresses, sendmail doesn’t actually use the /etc/aliases text file. For faster access, the text file is turned into a Berkeley database file, /etc/aliases.db, which resolves aliased addresses. For this reason, the newaliases command (equivalent to sendmail -bi) must be run to rebuild the database file each time the /etc/aliases text file is modified.




Red Hat Fedora Linux 3 Bible
Red Hat Fedora Linux 3 Bible
ISBN: 0764578723
EAN: 2147483647
Year: 2005
Pages: 286

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net