To set up your system as a mail server, you must configure the sendmail mail-transport agent properly and start the sendmail server. If you installed sendmail, it should already be configured to run when you boot Red Hat Linux. To check if this is true, type the following command:
chkconfig --list sendmail sendmail 0:off 1:off 2:on 3:on 4:on 5:on 6:off
The output shows whether sendmail is turned on or off for each of the run levels from 1 through 6 (consult Chapter 20 to learn more about run levels). If sendmail is configured to run automatically, you should see it set to on for at least the run levels 3 and 5. If it's off for all run levels, type the following command to turn it on:
chkconfig --level 35 sendmail on
To restart sendmail after making changes to configuration files, type the following command:
service sendmail restart
sendmail has the reputation of being a complex but complete mail-delivery system. If you take a quick look at sendmail's configuration file, /etc/mail/sendmail.cf, you'll immediately agree that sendmail is indeed complex. Luckily, you do not have to be an expert on the sendmail configuration file (a whole book has been written on that subject; see the 'Learning More about sendmail' section). All you need is one of the predefined configuration files from this book's companion CD-ROMs.
I have been able to send and receive email immediately after installing Red Hat Linux because sendmail is installed as part of the basic operating system package. To try out the sendmail mail-transfer agent, I have used the mail command to compose and send a mail message to myself at a different address, as follows:
mail email@example.com Subject: Testing email This is from my Red Hat Linux system. . Cc: Press Ctrl+D
The mail command is a simple mail-user agent. In the preceding example, I specify the firstname.lastname@example.org the command line. The mail program prompts me for a subject line. Following the subject, I enter my message and end it with a line that contains only a period. After I end the message, the mail-user agent passes the message to sendmail-the mail-transport agent-for delivery to the specified address. Because my system is already connected to the Internet, sendmail delivers the mail message immediately.
To verify the delivery of mail, I check my ISP mail account and I also send a short reply. (You cannot send a reply if your system does not have a hostname in the ISP's DNS database.) I can then read the reply on the Red Hat Linux PC by using the mail command.
Thus, the initial sendmail configuration file that comes with Red Hat Linux should be adequate for sending and receiving email, provided that your Red Hat Linux system has an Internet connection and a registered domain name.
On an Internet host, the sendmail mail-transport agent delivers mail using the Simple Mail Transfer Protocol (SMTP). SMTP is documented in RFC 821, 'Simple Mail Transfer Protocol,' by Jonathan Postel, 1982.
SMTP-based mail-transport agents listen to the TCP port 25 and use a small set of text commands to interact with other mail-transport agents. In fact, the commands are simple enough that you can use them directly to send a mail message. The following example shows how I use SMTP commands to send a mail message to my account on the Linux PC from a Telnet session running on the same system:
telnet localhost 25 Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. 220 dhcppc6.naba.com ESMTP Sendmail 8.12.7/8.12.7; Sun, 16 Feb 2003 11:44:19 -000 help 214-2.0.0 This is sendmail version 8.12.7 214-2.0.0 Topics: 214-2.0.0 HELO EHLO MAIL RCPT DATA 214-2.0.0 RSET NOOP QUIT HELP VRFY 214-2.0.0 EXPN VERB ETRN DSN AUTH 214-2.0.0 STARTTLS 214-2.0.0 For more info use "HELP <topic>". 214-2.0.0 To report bugs in the implementation send email to 214-2.0.0 email@example.com. 214-2.0.0 For local information send email to Postmaster at your site. 214 2.0.0 End of HELP info HELP DATA 214-2.0.0 DATA 214-2.0.0 Following text is collected as the message. 214-2.0.0 End with a single dot. 214 2.0.0 End of HELP info HELO localhost 250 dhcppc6.naba.com Hello localhost.localdomain [127.0.0.1], pleased to meet you MAIL FROM: naba 553 5.5.4 naba... Domain name required for sender address naba MAIL FROM: naba@localhost 250 2.1.0 naba@localhost... Sender ok RCPT TO: naba 250 2.1.5 naba... Recipient ok DATA 354 Enter mail, end with "." on a line by itself Testing... 1 2 3 Sending mail by telnet to port 25 . 250 2.0.0 h0BIAs8E004713 Message accepted for delivery quit 221 2.0.0 dhcppc6.naba.com closing connection Connection closed by foreign host.
The telnet command opens a Telnet session on port 25-the port on which sendmail expects SMTP commands. The sendmail server on the Red Hat Linux system immediately replies with an announcement.
I type HELP to view a list of SMTP commands. To get help on a specific command, I can type HELP commandname. The listing shows the help information sendmail prints when I type HELP DATA.
I type HELO localhost to initiate a session with the host. The sendmail process replies with a greeting. To send the mail message, I start with the MAIL FROM: command that specifies the sender of the message (I enter the user name on the system from which I am sending the message). sendmail requires a domain name along with the user name.
Next, I type the RCPT TO: command to specify the recipient of the message. If I want to send the message to several recipients, all I have to do is provide each recipient's address with the RCPT TO: command.
To enter the mail message, I type the DATA command. In response to the DATA command, sendmail displays an instruction that I should end the message with a period on a line by itself. I enter the message and end it with a single period on a separate line. The sendmail process displays a message indicating that the message has been accepted for delivery. Finally, I quit the sendmail session by typing the QUIT command.
Afterward, I log in to my Red Hat Linux system and check mail with the mail command. The following is what I see when I display the mail message I have sent through the sample SMTP session with sendmail:
mail Mail version 8.1 6/6/93. Type ? for help. "/var/spool/mail/naba": 1 message 1 new >N 1 firstname.lastname@example.org Sun Feb 16 13:14 12/454 & 1 Message 1: From email@example.com Sun Feb 16 13:14:07 2003 Date: Sun Feb 16 2003 13:10:54 -0500 From: Naba Barkakati <firstname.lastname@example.org> Testing... 1 2 3 Sending mail by telnet to port 25 & q Saved 1 message in mbox
As this example shows, the SMTP commands are simple enough to understand. This example should help you understand how a mail-transfer agent uses SMTP to transfer mail on the Internet. Of course, this whole process is automated by email programs and the sendmail program (through settings in the sendmail configuration file /etc/mail/sendmail.cf).
You don't need to understand everything in the sendmail configuration file, /etc/mail/ sendmail.cf, but you should know how that file is created. That way, you can make minor changes if necessary and regenerate the /etc/mail/sendmail.cf file.
Now that you have taken care of the prerequisites, you can learn how to regenerate the sendmail.cf file.
The m4 macro processor is used to generate the sendmail.cf configuration file, which comes with the sendmail package in Red Hat Linux. The main macro file, sendmail.mc, is included with the sendmail package, but that file needs other m4 macro files that are in the sendmail-cf package. To be able to process the sendmail.mc file, you have to install the sendmail-cf package, as explained in the previous section. This section introduces you to the m4 macro processor.
A macro is a symbolic name for some action or a long string of characters. A macro processor such as m4 usually reads its input file and copies it to the output, processing the macros along the way. The processing of a macro generally involves performing some action and generating some output. Because a macro generates a lot more text in the output than merely the macro's name, the processing of macros is referred to as macro expansion.
The m4 macro processor is the GNU implementation of the standard UNIX macro processor. Only a few simple m4 macros are described in this section, but there is much more to m4 than the simple examples shown here. It's essentially a new scripting language for generating configuration files. You can read the online manual about m4 by typing the command info m4 at a shell prompt. Chapter 23 describes how to read online help by using info.
To see a very simple use of m4, consider the following m4 macro file that defines two macros-hello and bye-and uses them in a form letter:
dnl ################################################### dnl # File: ex.m4 dnl # A simple example of m4 macros dnl ################################################### define(`hello', `Dear Sir/Madam')dnl define(`bye', `Sincerely, Customer Service')dnl dnl Now type the letter and use the macros hello, This is to inform you that we received your recent inquiry. We will respond to your question soon. bye
Type this text using your favorite text editor, and save it in a file named ex.m4. You can name a macro file anything you like, but it is customary to use the .m4 extension for m4 macro files.
Before you process the macro file by using m4, note the following key points the preceding example illustrates:
Use the dnl macro to start all the comment lines (for example, the first four lines in the example).
End each macro definition with the dnl macro. Otherwise, when m4 processes the macro file, it produces a blank line for each macro definition.
Use the built-in m4 command define to define a new macro. The macro name and the value are both enclosed between a pair of left and right quotes (`...'). Note that you cannot use the plain single quote to enclose the macro name and definition.
Now process the macro file ex.m4 by using m4 as follows:
m4 ex.m4 Dear Sir/Madam, This is to inform you that we received your recent inquiry. We will respond to your question soon. Sincerely, Customer Service
As you can see, m4 prints the form letter on standard output, expanding the macros hello and bye into their defined values. If you want to save the form letter in a file called letter, use the shell's output redirection feature, like this:
m4 ex.m4 > letter
What if you want to use the word hello or bye in the letter without expanding them? You can do so by enclosing these macros in a pair of left- and right-quotes (`...'). You have to do this for other predefined m4 macros, such as define. To use define as a plain word, not as a macro to expand, write `define'.
The simple example in the preceding section should give you an idea of how m4 macros are defined and used to create configuration files such as the sendmail.cf file. Essentially, many complex macros are written and stored in files in the /usr/share/sendmail-cf directory. A top-level macro file, sendmail.mc, described later in this section, brings in these macro files with the include macro (used to copy a file into the input stream).
By defining its own set of high-level macros in files located in the /usr/share/sendmail-cf directory, sendmail essentially creates its own macro language. The sendmail macro files use the .mc extension. The primary sendmail macro file you should configure is sendmail.mc, located in the /etc/mail directory.
Unlike the /etc/mail/sendmail.cf file, the /etc/mail/sendmail.mc file is short and should be easier to work with. Here is the full listing of the /etc/mail/sendmail.mc file that comes with Red Hat Linux:
divert(-1)dnl dnl # dnl # This is the sendmail macro config file for m4. If you make changes to dnl # /etc/mail/sendmail.mc, you will need to regenerate the dnl # /etc/mail/sendmail.cf file by confirming that the sendmail-cf package is dnl # installed and then performing a dnl # dnl # make -C /etc/mail dnl # include(`/usr/share/sendmail-cf/m4/cf.m4')dnl VERSIONID(`setup for Red Hat Linux')dnl OSTYPE(`linux')dnl dnl # dnl # Uncomment and edit the following line if your outgoing mail needs to dnl # be sent out through an external mail server: dnl # dnl define(`SMART_HOST',`smtp.your.provider') dnl # define(`confDEF_USER_ID',``8:12'')dnl dnl define(`confAUTO_REBUILD')dnl define(`confTO_CONNECT', `1m')dnl define(`confTRY_NULL_MX_LIST',true)dnl define(`confDONT_PROBE_INTERFACES',true)dnl define(`PROCMAIL_MAILER_PATH',`/usr/bin/procmail')dnl define(`ALIAS_FILE', `/etc/aliases')dnl dnl define(`STATUS_FILE', `/etc/mail/statistics')dnl 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 dnl # dnl # The following allows relaying if the user authenticates, and disallows dnl # plaintext authentication (PLAIN/LOGIN) on non-TLS links dnl # dnl define(`confAUTH_OPTIONS', `A p')dnl dnl # dnl # PLAIN is the preferred plaintext authentication method and used by dnl # Mozilla Mail and Evolution, though Outlook Express and other MUAs do dnl # use LOGIN. Other mechanisms should be used if the connection is not dnl # guaranteed secure. dnl # dnl TRUST_AUTH_MECH(`EXTERNAL DIGEST-MD5 CRAM-MD5 LOGIN PLAIN')dnl dnl define(`confAUTH_MECHANISMS', `EXTERNAL GSSAPI DIGEST-MD5 CRAM-MD5 LOGIN PLA IN')dnl dnl # dnl # Rudimentary information on creating certificates for sendmail TLS: dnl # make -C /usr/share/ssl/certs usage 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 # dnl # This allows sendmail to use a keyfile that is shared with OpenLDAP's dnl # slapd, which requires the file to be readable by group ldap dnl # dnl define(`confDONT_BLAME_SENDMAIL',`groupreadablekeyfile')dnl dnl # 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 dnl FEATURE(delay_checks)dnl 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 dnl # dnl # The -t option will retry delivery if e.g. the user runs over his quota. 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 EXPOSED_USER(`root')dnl dnl # dnl # The following causes sendmail to only listen on the IPv4 loopback address dnl # 127.0.0.1 and not on any other network devices. Remove the loopback dnl # address restriction to accept email from the internet or intranet. dnl # DAEMON_OPTIONS(`Port=smtp,Addr=127.0.0.1, Name=MTA')dnl dnl # dnl # The following causes sendmail to additionally listen to port 587 for dnl # mail from MUAs that authenticate. Roaming users who can't reach their dnl # preferred sendmail daemon due to port 25 being blocked or redirected find dnl # this useful. dnl # dnl DAEMON_OPTIONS(`Port=submission, Name=MSA, M=Ea')dnl dnl # dnl # The following causes sendmail to additionally listen to port 465, but dnl # starting immediately in TLS mode upon connecting. Port 25 or 587 followed dnl # by STARTTLS is preferred, but roaming clients using Outlook Express can't dnl # do STARTTLS on ports other than 25. Mozilla Mail can ONLY use STARTTLS dnl # and doesn't support the deprecated smtps; Evolution <1.1.1 uses smtps dnl # when SSL is enabled-- STARTTLS support is available in version 1.1.1. dnl # dnl # For this to work your OpenSSL certificates must be configured. dnl # dnl DAEMON_OPTIONS(`Port=smtps, Name=TLSMTA, M=s')dnl dnl # dnl # The following causes sendmail to additionally listen on the IPv6 loopback dnl # device. Remove the loopback address restriction listen to the network. dnl # dnl # NOTE: binding both IPv4 and IPv6 daemon to the same port requires dnl # a kernel patch dnl # dnl DAEMON_OPTIONS(`port=smtp,Addr=::1, Name=MTA-v6, Family=inet6')dnl dnl # dnl # We strongly recommend not accepting unresolvable domains if you want to dnl # protect yourself from spam. However, the laptop and users on computers dnl # that do not have 24x7 DNS do need this. dnl # FEATURE(`accept_unresolvable_domains')dnl dnl # dnl FEATURE(`relay_based_on_MX')dnl dnl # dnl # Also accept email sent to "localhost.localdomain" as local email. dnl # LOCAL_DOMAIN(`localhost.localdomain')dnl dnl # dnl # The following example makes mail from this host and any additional dnl # specified domains appear to be sent from mydomain.com dnl # dnl MASQUERADE_AS(`mydomain.com')dnl dnl # dnl # masquerade not just the headers, but the envelope as well dnl # dnl FEATURE(masquerade_envelope)dnl dnl # dnl # masquerade not just @mydomainalias.com, but @*.mydomainalias.com as well dnl # dnl FEATURE(masquerade_entire_domain)dnl dnl # dnl MASQUERADE_DOMAIN(localhost)dnl dnl MASQUERADE_DOMAIN(localhost.localdomain)dnl dnl MASQUERADE_DOMAIN(mydomainalias.com)dnl dnl MASQUERADE_DOMAIN(mydomain.lan)dnl MAILER(smtp)dnl MAILER(procmail)dnl
As the comments (the lines that begin with dnl) in the beginning of the file explain, you can generate the /etc/mail/sendmail.cf file by running the sendmail.mc file through the m4 macro processor with the following command (you have to log in as root):
m4 /etc/mail/sendmail.mc > /etc/mail/sendmail.cf
The comments also tell you that you need the sendmail-cf package to process this file.
From the previous section's description of m4 macros, you can see that the sendmail.mc file uses define to create new macros. You can also see the liberal use of dnl to avoid inserting too many blank lines into the output.
The other uppercase words such as OSTYPE, FEATURE, and MAILER are sendmail macros. These are defined in the .m4 files located in the subdirectories of the /usr/share/ sendmail-cf directory and are incorporated into the sendmail.mc file with the following include macro:
The /usr/share/sendmail-cf/m4/cf.m4 file, in turn, includes the cfhead.m4 file, which includes other m4 files, and so on. The net effect is that, as the m4 macro processor processes the sendmail.mc file, the macro processor incorporates many m4 files from various subdirectories of /usr/share/sendmail-cf.
Note the following key points about the /etc/mail/sendmail.mc file:
The VERSIONID(`linux setup for Red Hat Linux') macro inserts the version information enclosed in quotes into the output.
OSTYPE(`linux') specifies Linux as the operating system. You have to specify this early to ensure proper configuration. It is customary to place this macro right after the VERSIONID macro.
MAILER(smtp) describes the mailer. According to the /usr/share/sendmail-cf/README file, MAILER, declarations should always be placed at the end of the sendmail.mc file, and MAILER(`smtp') should always precede MAILER (`procmail'). The mailer smtp refers to the SMTP mailer.
FEATURE macros request various special features. For example, FEATURE (`blacklist_recipients') turns on the capability to block incoming mail for certain user names, hosts, or addresses. The specification for what mail to allow or refuse is placed in the access database (/etc/mail/access.db file). You also need the FEATURE(`access_db') macro to turn on the access database.
MASQUERADE_AS(`mydomain.com') causes sendmail to label outgoing mail as having come from the host mydomain.com (replace this with your domain name). The idea is for a large organization to set up a single sendmail server that handles the mail for many subdomains and makes everything appear to come from a single domain (for example, mail from many departments in a University would appear to come from the University's main domain name).
MASQUERADE_DOMAIN(subdomain.mydomain.com) instructs sendmail to send mail from an address such as email@example.com as having originated from the same user name at the domain specified by the MASQUERADE_AS macro.
The sendmail macros such as FEATURE and MAILER are described in the /usr/ share/sendmail-cf/README file. Consult that file to learn more about the sendmail macros before you make changes to the sendmail.mc file.
The sendmail.cf file's syntax is designed to be easy to parse by the sendmail program because sendmail reads this file whenever it starts. Human readability was not a primary consideration when the file's syntax was designed. Still, with a little explanation, you can understand the meaning of the control lines in sendmail.cf.
Table 15-1 summarizes the one-letter control operators used in sendmail.cf. Each entry also shows an example of that operator. This table should help you understand some of the lines in sendmail.cf.
Defines a class; a variable (think of it as a set) that can contain several values. For example, Cwlocalhost adds the name localhost to the class w.
Defines a macro, a name associated with a single value. For example, DnMAILER-DAEMON defines the macro n as MAILER-DAEMON.
Defines a class read from a file. For example, Fw/etc/mail/local-host-names reads the names of hosts from the file /etc/mail/local-host-names and adds them to the class w.
Defines the format of header lines that sendmail inserts into a message. For example, H?P?Return-Path: <$g> defines the Return-Path: field of the header.
Defines a map (a key-value pair database). For example, Karith arith defines the map named arith as the compiled-in map of the same name.
Specifies a mailer. The following lines define the procmail mailer:Mprocmail, P=/usr/bin/procmail,F=DFMSPhnu9,S=EnvFromSMTP/HdrFromSMTP, R=EnvToSMTP/HdrFromSMTP,T=DNS/RFC822/X-Unix, A=procmail -Y -m $h $f $u
Assigns a value to an option. For example, O AliasFile=/etc/aliases defines the AliasFile option to /etc/aliases, which is the name of the sendmail alias file.
Defines values for the precedence field. For example, Pjunk=-100 sets to -100 the precedence of messages marked with the header field Precedence: junk.
Defines a rule (a rule has a left-hand side and a right-hand side; if input matches the left-hand side, it's replaced with the right-hand side-this is called rewriting). For example, the rewriting rule R$* ; $1 strips trailing semicolons.
Labels a ruleset you can start defining with subsequent R control lines. For example, Scanonify=3 labels the next ruleset as canonify or ruleset 3.
Adds a user name to the trusted class (class t). For example, Troot adds root to the class of trusted users.
Defines the major version number of the configuration file. For example, V10/Berkeley defines the version number as 10.
The /etc/mail directory contains other files that sendmail uses. These files are referenced in the sendmail configuration file, /etc/mail/sendmail.cf. For example, here's the result of searching for the /etc/mail string in the /etc/mail/sendmail.cf file:
grep "\/etc\/mail" /etc/mail/sendmail.cf Fw/etc/mail/local-host-names FR-o /etc/mail/relay-domains Kmailertable hash -o /etc/mail/mailertable.db Kvirtuser hash -o /etc/mail/virtusertable.db Kaccess hash -T<TMPF> -o /etc/mail/access.db #O ErrorHeader=/etc/mail/error-header O HelpFile=/etc/mail/helpfile O StatusFile=/etc/mail/statistics O UserDatabaseSpec=/etc/mail/userdb.db #O ServiceSwitchFile=/etc/mail/service.switch #O DefaultAuthInfo=/etc/mail/default-auth-info Ft/etc/mail/trusted-users
You can ignore the lines that begin with a hash mark or number sign (#) because sendmail treats those lines as comments. The other lines are sendmail control lines that refer to other files in the /etc/mail directory.
The next few sections briefly describe a few of these sendmail configuration files in the /etc/mail directory.
The user database helps sendmail deliver incoming mail when there is no centralized mail server. For example, suppose mail addressed to firstname.lastname@example.org should really be sent to email@example.com. This involves identifying a user's maildrop-the location where a user receives mail-to sendmail. You can accomplish this task by creating the user database.
sendmail expects the user database in a binary file /etc/mail/userdb.db in the Berkeley database format. Follow these steps to create the binary user database file:
Edit the text file /etc/mail/userdb and add lines for each user for whom you need to identify a maildrop location. The lines look like this:
loginname:mailname firstname.lastname@example.org emailname:maildrop loginname@home
Convert the text file /etc/mail/userdb into a Berkeley database file that sendmail can use by running the makemap with the following command:
makemap btree /etc/mail/userdb < /etc/mail/userdb
This creates the database file /etc/mail/userdb.db from the text file /etc/mail/userdb.
You must remember to run makemap every time you change /etc/mail/userdb, otherwise sendmail will not be using your latest user database when sending mail.
The mailer table database specifies how to route email messages destined for specific domains. You specify these mail routings in a text file /etc/mail/mailertable. For
example, suppose all mail meant for the mydomain.net should be sent to the host mailhost.mydomain.net. You can specify this with the following entry in /etc/mail/ mailertable:
The left-hand side of each line is a domain name. The right-hand side is of the form mailer:host, where mailer is a mail transfer agent and host is the hostname to be provided to that mailer.
After editing the text file /etc/mail/mailertable, you have to convert it into a binary database by running makemap with the following command:
makemap hash /etc/mail/mailertable < /etc/mail/mailertable
The access database causes sendmail to accept or refuse mail from specified domains and also control the behavior of sendmail in various situations. The database is a list of names (user names, hostnames, or network addresses) and codes that specify the action sendmail performs.
Users can redirect their own mail by placing a .forward file in their home directory. The .forward file is a plaintext file with a comma-separated list of mail addresses. Any mail sent to the user is then forwarded to these addresses. If the .forward file contains a single address, all email for that user is redirected to that single email address. For example, suppose that the following .forward file is placed in the home directory of a user named emily:
All email addressed to emily is automatically sent to the user name ashley on the same system. User emily does not receive mail at all.
You can also forward to a user name on another system by listing the complete email address. For example, I have added a .forward file with the following line to send my messages (addressed to my user name, naba) to the mail address email@example.com:
Now, suppose I want to keep a copy of the message on this system, in addition to forwarding to the address firstname.lastname@example.org. I can do so by adding the following line to the .forward file:
I simply append my user name and end the line with a backslash. The backslash (\) at the end of the line stops sendmail from repeatedly forwarding the message (because when a copy is sent to my user name on the system, sendmail processes my .forward file again-the backslash tells sendmail not to forward the message repeatedly).
With procmail, you can perform other chores, such as automatically storing messages in a file or forwarding messages to others. All you have to do is create an appropriate .procmailrc file in your home directory. To learn more about procmail, type man procmail; to see examples of .procmailrc, type man procmailex.
In addition to the sendmail.cf file, sendmail also consults an alias file named /etc/aliases to convert a name into an address. The location of the alias file appears in the sendmail configuration file.
Each alias is typically a shorter name for an email address. The system administrator uses the sendmail alias file to forward mail, to create mailing lists (a single alias that identifies several users), or to refer to a user by several different names. For example, here are some typical aliases:
barkakati: naba naba: naba@lnbsoft all: naba, leha, ivy, emily, ashley
The first line says that mail addressed to barkakati should be delivered to the user named naba on the local system. The second line indicates that mail for naba should really be sent to the user name naba on the lnbsoft system. The last line defines all as the alias for the five users naba, leha, ivy, emily, and ashley.
As the next section explains, you can set up a mailing list simply by defining an alias in the /etc/aliases file.
You can implement a simple mailing list through a sendmail alias. In its simplest form, all you have to do is define an alias for the addresses in the /etc/aliases file. For example, suppose a large company has several websites (one in each major department), and the Webmasters decide to keep in touch through a mailing list. One of the Webmasters, Emily, volunteers to set up a mailing list for the group. To set up the mailing list, Emily (who logs in with the user name emily) adds the following alias to the /etc/aliases file:
webmasters: emily, webmaster@sales, webmaster@mktg, webmaster@appdev, ..., ..., webmaster@admin
In this case, the address list includes Emily and the Webmasters at all websites in the company (typically, mail to the Webmaster is addressed to the user name webmaster). If the list of addresses gets too long, end a line with a comma, and indent the next line with a tab character.
After defining an alias in the /etc/aliases file, you must log in as root and make the new alias active by typing the following command:
You can use the absolute path name /usr/lib/sendmail to run sendmail because /usr/lib/sendmail is a symbolic link to the actual sendmail program file /usr/ sbin/sendmail.
In addition to the webmasters alias, it's conventional to define two other aliases:
The alias listname-request is where users send mail to subscribe to (or unsubscribe from) the list.
The alias owner-listname is where errors (such as bounced messages) are sent.
In this case, because Emily sets up the Webmasters list, she might define the two aliases as follows:
webmasters-request: emily owner-webmasters: emily
For a simple mailing list, one person is usually responsible for everything about the list.
Although defining an alias with all the addresses works, the drawback is that you must edit the /etc/aliases file whenever you want to add a new name to the list. You need to log in as root to edit the /etc/aliases file (or ask the system administrator to edit the file for you). A better solution is to store the address list in a separate file in your home directory and make sendmail read that file with the :include: directive in the alias definition.
For example, Emily might put the address list for the webmasters alias in the /home/emily/mlist/webms file (assuming that /home/emily is the login directory of user emily). Then the /etc/aliases file would reference the address list as follows:
In the /home/emily/mlist/webms file, each address appears on a separate line:
emily (Emily B. -- list owner) webmaster@appdev (Webmaster, Application Development Group) webmaster@mktg (Webmaster, Marketing Department)
As you can see, you can put helpful comments in parentheses.
Every time sendmail sends a message to the webmasters alias, it reads the /home/emily/mlist/webms file. Thus, you can add a new user by simply editing this file.
If you use an address file, make sure that only the owner can modify it. Use the command chmod 644 filename to set the permission properly.
When you set up a mailing list, you want any replies to go to everyone in the list so that discussions can take place among the group. However, when you use a sendmail alias to define a mailing list, the reply goes to the person who has sent the message instead of to the entire list. You can correct this problem by making the alias start a new sendmail process and by changing the sender's address through the -f option of sendmail.
Here's how you define the webmasters list by using this approach:
webmasters: "|/usr/lib/sendmail -fwebmasters -oi dist-webmasters" dist-webmasters: :include:/home/emily/mlist/webms
This definition of
Part III: Internetworking with Red Hat Linux