Email Brian
Brian's Website
Email Tom
Tom's Website
|
Email Brian Brian's Website |
|
Email Tom Tom's Website |
Did you read the Preface? Thanks!
In the beginning there was the ARPANET, which was designed as a tool to provide for communication between academic researchers, corporate labs, and Department of Defense sponsors. Quickly, e-mail became a primary method of communication on this network that was linked by a variety of leased line and dialup connections.
At UC Berkeley, a graduate student named Eric Allman addressed the requirements of converting mail between the ARPANET, and two local networks (a UUCP network (Unix-to-Unix Copy Protocol), and another called BerkNET) by writing delivermail, the predecessor to Sendmail. When ARPANET made the transition to using TCP, a new mail transfer protocol was designed: SMTP. This stands for Simple Mail Transfer Protocol, and was a vast improvement over using FTP to move mail from host to host.
As the disparate academic, corporate, and governmental networks made these evolutionary transitions over a period of several years, Allman rewrote the relatively inflexible delivermail program, and renamed the product Sendmail. This new program was able to (mostly) cope with a great variety of message types. Each different network type had a distinct format for their e-mail messages.
Eric wrote Sendmail to interpret the data in any given message, and construct a rational message header that would allow each message to be forwarded to its destination elsewhere on the networks. This was a much more desirable result than delivermail's practice of rejecting messages with malformed headers.
More Information
Now for a quick visit to metaphor central: The header of an e-mail message is the equivalent of an envelope. It has information about the sender and the intended recipient. As it passes through mail servers, it accumulates additional records, rather like a passport that is stamped at each border crossing.
From this start, Sendmail exploded onto the networks, being adopted and adapted by a variety of corporate and educational entities to meet a plethora of conflicting purposes. This baby boom meant that there were nearly as many distinct Sendmail versions as there were installations (or at least it seemed that way at the time).
In the 1990s, Eric Allman wrote yet another version of Sendmail, V8.7, which incorporated many of the best features of each of the offspring, while improving security. This trend has continued: V8.9, with some important security updates (including denial of relaying as a default, plus significant anti-spam features) is the version included with OpenLinux.
The release cycle of Sendmail is interesting as well. Each source release of Sendmail lags the commercial edition from Sendmail, Inc. by one revision level. The for-profit versions incorporate an assortment of ease-of-use features, plus GUI and remote/Web administration tools. Just for fun we had a look: Sendmail pricing starts at about $500 and runs quickly up into the thousands, as befits an enterprise-capable tool.
The Open Source version is covered by an agreement that reads like a modified BSD license. Sendmail is now in version 8.11.1, available as a download from ftp://ftp.sendmail.org/pub/sendmail/. This newest version includes SMTP authentication features, as well as Transport Layer Security (the successor to SSL) support. For the purposes of this chapter, however, we'll work with the stock package from eDesktop.
Let's have a brief look at a typical complete e-mail message.
From [email protected] Sun Oct 22 13:22:58 2000
Return-Path: <[email protected]>
Received: from syroidmanor.com (hydras [142.165.206.61])
by mail.orbdesigns.com (8.9.3/8.9.3) with ESMTP id NAA29274
for <[email protected]>; Sun, 22 Oct 2000 13:22:54 -0700
Received: from [192.168.0.1] (HELO [192.168.0.1])
by syroidmanor.com (CommuniGate Pro SMTP 3.4b2)
with ESMTP id 300154 for [email protected]; Sun, 22 Oct 2000 14:23:07 -0600
Date: Sun, 22 Oct 2000 14:23:09 -0600
From: Tom Syroid <[email protected]>
To: Brian Bilbrey <[email protected]>
Subject: Samba Intro
Message-ID: <1561980165.972224589@[192.168.0.1]>
X-Mailer: Mulberry/2.0.5b3 (Win32)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="==========1561987585=========="
Status: RO
Content-Length: 31206
Lines: 419
--==========1561987585==========
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Thanks -- got CH27 back.
Would you please have a glance through the attached intro. I've been though
it too many times in the last 24 hours, and I'm starting to lose
perspective. It's seems OK to me at this stage, but I'd like you to read it
before I plunk it in. That way the only thing you won't have seen when I
submit is the summary -- and a summary is a summary, eh?
/tom
--==========1561987585==========
Content-Type: application/msword; name="samba-intro.doc"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="samba-intro.doc"; size=22528
* * * MIME-encoded attachment contents removed * * *
--==========1561987585==========--
The parts that Sendmail cares about are all at the top of the message, which indicate where a message is coming from, and where it is going. Tom, up at Syroid Manor, is running CommuniGate Pro, a commercial mailer running on AIX. This can be seen in the latter "Received:" line in the message header section. This is actually the first entry that was attached to this message, as it reflects the local time in Saskatoon when the message was received, then sent on by the Syroid Manor server, from Tom's mail client.
The previous received line was added by Sendmail locally at the Orb Designs server in Sunnyvale, some 15 seconds before it was sent from Canada. Don't worry; it's a clock setting problem, rather than a time warp.
As a given message passes through a succession of mail servers (which is common in many corporate environments), each mail server appends its stamp of reception. However, on the crossing from Saskatoon to Sunnyvale, there are 19 hops (routers that forward traffic to get data to its destination), on average. So where are the other 19 stamps?
In this case, the message is encoded and packetized, then passed from syroidmanor.com to orbdesigns.com as standard TCP/IP traffic. Only when it arrived at port 25 (the standard SMTP port) at orbdesigns.com is it reassembled and received by a mail server. If the message were then forwarded on to another server, there would be two more sections, one departing Orb Designs, and the next marking reception at the destination, for a total of four "Received:" sections.
How Sendmail reads and interprets message headers is set up in the configuration file. In OpenLinux, this file is /etc/sendmail.cf. Other distributions might locate this file in /etc/mail/sendmail.cf. We'll dive into this configuration file following a brief introductory passage to some system documentation on Sendmail.
As we noted in the overview section in Chapter 24, this program is an MTA: a Mail Transport Agent. In and of itself, Sendmail only provides a method for getting e-mail messages from one location to another. It doesn't parse mail into user mailboxes like procmail, it doesn't serve POP3 or IMAP messages, and it isn't an e-mail client like Kmail, Mutt, or Netscape Messenger.
One starting point for learning more about Sendmail is the Installation and Operation Guide. Under eDesktop, this file is found at /usr/share/sendmail-8.9.3/op/op.ps.gz. Use the KDE File Manager to navigate to the file, and select it to dynamically decompress and display the Guide in the PS Viewer, as shown in Figure 25-1.
Figure 25-1
The Sendmail Installation and Operation Guide, open in the KDE2 PS Viewer.
The Guide is 76 tightly written pages, useful more for the wizard than the acolyte. The first two sections (through page 19) contain just enough information to help a new user begin to ask intelligent questions: It starts with instruction on compiling from sources (using the older "build" method, rather than the more recent GNU autoconf utility). This is quickly followed by an overview of various configuration and log files, and the executables that are associated with Sendmail. These include sendmail, newaliases, mailq, hoststat, and purgestat. We'll examine these in the section "Running Sendmail" later in this chapter.
The latter parts of the Guide walk a more experienced user through some advanced configuration and testing techniques. Rulesets (ways in which messages are rewritten to enable proper delivery), and many configuration macros are explained.
We've found two interesting truths about the Installation and Operation Guide. First, it's a handy searchable reference file if you know what question to ask. Second, some of the crucial beginners' questions have confusing answers because Sendmail is rooted in the conventions of BSD UNIX. The port to Linux works just fine, but much of the documentation seems slightly off-kilter as a result of references to certain files and directories that are specific to the BSD way of doing things. While not all the references click, this remains a better reference than the manual pages for Sendmail, which are slightly (grin) more opaque.
This is wholly understandable. Eric Allman puts it best in the beginning of the Guide:
"The Sendmail configuration can be daunting at first. The world is complex, and the mail configuration reflects that. The distribution includes an m4-based configuration package that hides a lot of the complexity."
Of course you can and should read at the manual pages for sendmail and aliases. The latter especially provides some crucial information that we'll be putting to use later. Additionally, there are several good and important resources documented at the end of this chapter. You'll need most of them if you intend to work with Sendmail in any serious way.
Now let's have a look deep under the hood, and glance at Sendmail's configuration facilities.
"He who has never hacked sendmail.cf has no soul;
he who has hacked sendmail.cf more than once has no brain."
- Old Hacker Proverb
We found that quote on a tutorial site at the University of Illinois (http://www-wsg.cso.uiuc.edu/sendmail/tutorial/). The truth of the proverb is found in the file itself. Caldera's version of /etc/sendmail.cf, included with eDesktop 2.4 is ... challenging, with many passages like the following excerpt (the complete file is 1,226 lines long!):
######################################################################
######################################################################
#####
##### REWRITING RULES
#####
######################################################################
######################################################################
############################################
### Ruleset 3 -- Name Canonicalization ###
############################################
S3
# handle null input (translate to <@> special case)
R$@ $@ <@>
# strip group: syntax (not inside angle brackets!) and trailing semicolon
R$* $: $1 <@> mark addresses
R$* < $* > $* <@> $: $1 < $2 > $3 unmark <addr>
R@ $* <@> $: @ $1 unmark @host:...
R$* :: $* <@> $: $1 :: $2 unmark node::addr
R:include: $* <@> $: :include: $1 unmark :include:...
R$* [ $* : $* ] <@> $: $1 [ $2 : $3 ] unmark IPv6 addrs
R$* : $* [ $* ] $: $1 : $2 [ $3 ] <@> remark if leading colon
Rlhs rhs optional comment
The "lhs" is the Left Hand Side, or input to the rule. The "rhs" (Right Hand Side) is the re-write rule applied to the input, if the input matches the "lhs." A comment is optional, but common (if cryptic to the uninitiated). Each of the three parts of a rule line can have spaces in it, but each part must be separated from the others by one or more explicit tab characters. Each ruleset is tasked with specific elements of message processing; data is passed from rule to rule, and forwarded to other rulesets as necessary. Here's an example of address processing using the ruleset test (-bt) option of Sendmail:
[root@gwydion /etc]# sendmail -Csendmail.cf -bt
ADDRESS TEST MODE (ruleset 3 NOT automatically invoked)
Enter <ruleset> <address>
> 3 Tom Syroid <[email protected]>
rewrite: ruleset 3 input: Tom Syroid < tom @ mail . syroidmanor . com >
rewrite: ruleset 96 input: tom < @ mail . syroidmanor . com >
rewrite: ruleset 96 returns: tom < @ syroidmanor . com . >
rewrite: ruleset 3 returns: tom < @ syroidmanor . com . >
>
In the listing, Ruleset 3 is applied to extract the actual e-mail address from the input string, then separate the user name from the host portion of the address. Then that version is passed to Ruleset 96, which performs a DNS query to provide canonical hostname resolution (turning mail.syroidmanor.com into syroidmanor.com). The return path is through the calling ruleset, after which the rewrite is complete. While /etc/sendmail.cf is clearly not designed for the convenience of administrator configuration, it is a format that permits rapid message processing. Exit Sendmail's Address Test Mode by typing Ctrl + D.
Fortunately, we're not going to ask you to configure Sendmail by creating rules manually. That would be like watching you try to make a fire by rubbing two sticks together while we stood by with a Zippo lighter, snickering. In this case, the lighter is an M4 configuration file called generic-col2.2.mc.
GNU M4 is a macro processor, fundamentally compatible with the AT&T System V Unix utility of the same name. According to the primary documentation (in Info format: type info m4 to access the manual), few users are aware of its existence. It's been used for a number of years to translate configuration files from a vaguely human readable format into the obtuse *.cf format that Sendmail uses.
Recently, M4 has seen quite a bit more action, as it is required for the GNU autoconf (automatic configuration) utility, which uses it to generate the configure files that are now common for building applications from source. Here's the calling syntax for M4:
m4 [-opts] [macro defs] [input]
M4 can be invoked at the command line to process input from files or from STDIN (either as a filter or from the keyboard). In the following short example, we start M4, and type the word foo, which M4 echoes. Then we define a macro to redefine "foo" to return "bar" and test that. Finally, we define "bar" to be re-written as "Caldera OpenLinux". Now, when we type foo the input is scanned, a substitution is made, then the revised line is scanned again, and the second macro is effected. After no more expansion is possible, the output string is written.
[bilbrey@gwydion /etc]$ m4
foo
foo
define(foo, bar)
foo
bar
define(bar, 'Caldera OpenLinux')
foo
Caldera OpenLinux
This multi-pass functionality is what gives M4 its personality and power. Simple configuration files, in conjunction with a straightforward set of macro definitions, can be expanded into complex and seemingly incomprehensible output files. Oh, yeah. You can get out of M4 in a terminal by typing either Ctrl + D (End of File) or Ctrl + C (Terminate).
In OpenLinux, change directories to /usr/share/sendmail/cf/cf/. A quick listing of the directory shows a large number of possibilities for configuration:
[root@gwydion cf]# ls
Build generic-bsd4.4.cf generic-solaris2.mc python.cs.mc
Makefile generic-bsd4.4.mc generic-sunos4.1.cf s2k-osf1.mc
chez.cs.mc generic-col2.2.mc generic-sunos4.1.mc s2k-ultrix4.mc
clientproto.mc generic-hpux10.cf generic-ultrix4.cf tcpproto.mc
cs-hpux10.mc generic-hpux10.mc generic-ultrix4.mc ucbarpa.mc
cs-hpux9.mc generic-hpux9.cf huginn.cs.mc ucbvax.mc
cs-osf1.mc generic-hpux9.mc knecht.mc uucpproto.mc
cs-solaris2.mc generic-nextstep3.3.mc mail.cs.mc vangogh.cs.mc
cs-sunos4.1.mc generic-osf1.cf mail.eecs.mc
cs-ultrix4.mc generic-osf1.mc mailspool.cs.mc
cyrusproto.mc generic-solaris2.cf obj
The .mc file extension is a mnemonic for M4 Configuration, the roughly human usable form of a Sendmail setup. There are many different platforms that run Sendmail, and the developers have done their best to provide basic configuration information for each. This includes standard directory structures for the various operating systems. We've used extra bold text in the middle of the directory listing above, to highlight the Caldera-specific offering (which hasn't needed change over two major OpenLinux revisions).
The general instructions for using the .mc files to create a Sendmail configuration are located one directory level up, at /usr/share/sendmail/cf/README. We'll summarize this for you as we go through customizing and processing the generic Caldera version into something we can use for our requirements. Work as the root user when using the following listings. First, make a local copy of the generic file, and make sure the group ownership of the file is mail:
[root@gwydion cf]# cp generic-col2.2.mc gwydion.orb-col2.2.mc
[root@gwydion cf]# chown root.mail gwydion.orb-col2.2.mc
[root@gwydion cf]# vi gwydion.orb-col2.2.mc
Then open the new file. Over the next few pages, we'll list most of the file, interspersed with explanations. Where we make (minimal) changes to the default file, the listing is printed with a bold code font.
divert(0)
#
# Copyright (c) 1996, 1997 Caldera Inc., Provo
#
The divert directive of M4 is used to instruct the macro processor in broad strokes regarding the block of input that follows. divert(0) means regular output. divert(-1) instructs M4 to discard the text that follows - neither process it nor echo it to the output file.
divert(-1)
# THIS SOFTWARE IS PROVIDED BY Caldera AND CONTRIBUTORS ``AS IS'' AND
# ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
# IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
# ARE DISCLAIMED. IN NO EVENT SHALL Caldera OR CONTRIBUTORS BE LIABLE
# FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
# DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
# OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
# HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
# LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
# OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
# SUCH DAMAGE.
After pitching out the fine print, normal output is restored below, with a new addition to the instruction. A by-product of M4 processing passes newline characters through by default. The trailing dnl command discards through the NewLine.
divert(0)dnl
#
# This is a generic configuration file for Caldera OpenLinux 2.2
#
# Basic ideas taken from Red Hat contrib/sendmail-8.7.5-1.src.rpm.
# Credits go to Marc (whoever built it).
# gwydion.orb-col2.2.mc modified from generic-col2.2.mc 11/03/00 bpb
#
VERSIONID(`$Id: gwydion.orb-col2.2.mc,v 1.4 1999/02/23 15:36:07 okir Exp $')
The version ID is written to the output .cf file during processing.
divert(-1)
OSTYPE(`linux')
M4 cannot build a configuration without OSTYPE called out before the MAILER definitions. See /usr/share/sendmail/cf/ostype/ for details on the various supported platforms. In the segments that follow, the dnl directive is used to prevent processing specific lines.
undefine(`UUCP_RELAY')
undefine(`BITNET_RELAY')
undefine(`LOCAL_MAILER_PATH')
dnl ##############################################################
dnl # Changed Aug/20/1997 --okir
dnl # we now use FEATURE(local_procmail)
dnl define(`LOCAL_MAILER_PATH', `/usr/bin/procmail')
dnl define(`LOCAL_MAILER_FLAGS', `SPfhnu9')
dnl define(`LOCAL_MAILER_ARGS', `procmail -Y -a $h -d $u')
define(`STATUS_FILE', `/var/log/sendmail.st')
define(`HELP_FILE', `/usr/share/sendmail/sendmail.hf')
define(`confUNSAFE_GROUP_WRITES', `True')
In the preceding segment, the old style of enabling Procmail (a local mail delivery utility) is commented out, prefaced by direction to use FEATURE(local_procmail) to enable that functionality, if desired. Available features including comprehensible descriptions are listed in the "FEATURES" section of /usr/share/sendmail/cf/README. Whether simple or complex, features are set with the following uncomplicated syntax:
FEATURE(feature_name, [, optional_parameter])
While we can't recommend making much in the way of changes without learning a lot more than is offered in these few pages, there is a vast range of functionality that's available through FEATURES, from using the RBL (Real Time Blackhole list) to masquerading multiple local hosts under a single canonical domain and much more.
Following the unused Procmail section a pair of file locations are defined, for status and help files. Then confUNSAFE_GROUP_WRITES is set to True. This means that the mail processing files .redirect and .forward that can exist in a user directory must not be group writeable, or they are considered unsafe by Sendmail and disregarded. There are many M4 variables of the confXXXX format that can be used. Search for the section called "TWEAKING CONFIGURATION OPTIONS" in the README file.
dnl ##############################################################
dnl # gwydion.orbdesigns.com local definitions
dnl # Message size 10MB
define(`confMAX_MESSAGE_SIZE', `10485760')
dnl # setup correct canonical domain, and rewrite all addresses
MASQUERADE_AS(`orbdesigns.com')
FEATURE(allmasquerade)
Since the authors move large files back and forth via e-mail, we've bumped the file size limit up to 10MB. Also, we set the canonical hostname for the domain, so that all outgoing mail is rewritten correctly.
dnl ##############################################################
dnl # sendmail comes with a program called smrsh, which restricts
dnl # the programs that can be executed as a result of an alias or
dnl # .forward expansion. Only those commands found in /usr/libexec/sm.bin
dnl # can actually be executed (for details, see smrsh(8)).
dnl #
dnl FEATURE(`smrsh', `/usr/libexec/sm.bin')
dnl ##############################################################
dnl # Use mail.local as the local delivery agent
dnl #
FEATURE(local_lmtp, `/usr/libexec/sendmail/mail.local')
dnl ##############################################################
dnl # Enable the .REDIRECT feature in alias lookups
dnl #
FEATURE(redirect)
dnl ##############################################################
dnl #
dnl #
FEATURE(always_add_domain)
dnl ##############################################################
dnl # Let the user specify host aliases in sendmail.cw
dnl #
dnl The following doesn't seem to work..
dnl define(confCW_FILE, `/etc/sendmail/sendmail.cw')
FEATURE(use_cw_file)
We find that the comment "doesn't seem to work" is most likely the result of migrating a previously working .mc file into the newest V8.x. Sendmail's M4 definitions are in a continual process of improvement and flux, and items that worked several revisions ago have been first deprecated, then removed from service.
dnl ##############################################################
dnl # We provide a mailertable to fine-tune routing.
dnl #
FEATURE(mailertable, `hash /etc/sendmail/mailertable')
dnl ##############################################################
dnl # Include COL setup
dnl #
ifdef(`COL_FEATURES',,`define(`COL_FEATURES',`/dev/null')')
include(COL_FEATURES)
After a fruitless search, we've determined that COL_FEATURES apparently don't exist!
dnl ##############################################################
dnl # Do not limit message sizes for UUCP mailer
define(`UUCP_MAILER_MAX', 0)
dnl ##############################################################
dnl # Include the following mailers:
dnl #
MAILER(local)
MAILER(smtp)
MAILER(uucp)
Finally the file closes with the MAILER definitions. These provide the Rulesets that are used to cope with various types of common addressing schemes. The three shown: local, smtp, and uucp, should always be present in most environments. There are several others defined - these are documented in the README file.
Local mail is that which is sent from user to user within a single host. Mail never has to leave the machine to get to its destination. SMTP (for Simple Mail Transport Protocol) messages are the most common in use today, and UUCP (Unix to Unix Copy) is second, as it was the protocol in use prior to SMTP. Many large academic networks still use UUCP for mail transport.
Next, process the M4 configuration file:
[root@gwydion cf]# m4 ../m4/cf.m4 gwydion.orb-col2.2.mc > gwydion.cf
This runs the M4 macro processor, preloads the cf.m4 definitions and takes the revised file, gwydion.orb-col2.2.mc as input. Using command line redirection (the '>' character), the output is written to the new configuration file, gwydion.cf. This takes just about one second to run.
The output of our processed 90-line input file is a 1,230-line .cf file. Since we actually changed the default maximum messages size in this pass, we'll replace the default configuration. To do so, rename the old sendmail.cf (in case of emergency), and then copy the new .cf file to /etc/sendmail.cf.
Other changes that we need to make are in the aliases file (which determines the accounts that Sendmail works with) and sendmail.cw, to setup the hosts for which Sendmail will process messages.
There are several important files that provide Sendmail with the necessary information to correctly deliver local mail, ascertain the identity of trusted external hosts, and decide if mail that arrives addressed to a specific host is to be accepted. These jobs and others are delegated among the following files described here.
Rebooting not required...
After any changes, reload the Sendmail configuration files by typing/etc/rc.d/init.d/mta reloadafter making any changes. Otherwise the modified files are not re-read until the system is rebooted or the service is otherwise stopped and restarted.
Sendmail uses aliases to perform various types of redirections on incoming messages. Mail can be directed to another address or a list of addresses, appended to a file, or piped through a program. Here's the default OpenLinux /etc/aliases file:
#
# This file lists the default mail aliases for Caldera OpenLinux.
#
# Aliases in this file will NOT be expanded in the header from
# Mail, but WILL be visible over networks or from /bin/mail.
#
# IMPORTANT NOTE:
#
# After you make any changes to this file, you have to run
#
# /usr/sbin/mta-switch newconfig
#
# or the program `newaliases' (works for smail and sendmail).
# Otherwise the changes won't be visible to your MTA.
#
# Basic system aliases -- these MUST be present.
MAILER-DAEMON: postmaster
postmaster: root
# General redirections for pseudo accounts.
bin: root
daemon: root
adm: root
games: root
ingres: root
system: root
toor: root
news: root
uucp: root
operator: root
ftp: root
nobody: root
# Well-known aliases.
manager: root
dumper: root
newsadm: news
newsadmin: news
usenet: news
netnews: news
gnats: root
ftpadm: ftp
ftpadmin: ftp
ftp-adm: ftp
ftp-admin: ftp
# trap decode to catch security attacks
decode: root
# Person who should get root's mail
root: col
This is one of the nicest self-documenting files we've come across in our explorations of OpenLinux. System accounts that don't (or shouldn't) have mail access are aliased to more commonly accessible names. To work with additional users or accounts, simply add user names in the correct arrangement then run newaliases, and it just works. Of course, there's more to it than that. Here's the format of the four types of alias entry.
local: user [, user ...]
local: /file
local: |program
local: :include: list
Every local item must either be a valid local user name, or it needs to alias to a valid name or a routable [email protected]. One or more user names or addresses can appear on the right. If more than one, then the message is sent to all recipients. If the right hand side of an alias starts with a "/", then Sendmail assumes the target is a file, and appends the message the filename specified. Use of the pipe character "|" delivers the message as input to the given program name (which should be specified using the complete path to the executable). The special ":include:" item permits external alias lists, which is very useful (departmental definitions, for example).
Now edit the file to match your local requirements, and create the aliases database using newaliases.
[root@gwydion /etc]# vi aliases
* * *
# Person who should get root's mail
root: bilbrey
# Other aliases
syroid: [email protected]
ols.book: bilbrey, syroid
[root@gwydion /etc]# newaliases
/etc/aliases: 28 aliases, longest 19 bytes, 303 bytes total
The default col user doesn't exist on the system, so we change the root redirection to send the administrative mail to bilbrey. Mail destined for the local user account syroid is forwarded out to Tom, at his [email protected] address. Be alert, though. There is a limit to how many servers a message can pass through (called "hops"). This generally isn't a problem except in deeply layered corporate mail systems.
Then we set up an address for mail about this book, so that messages addressed to [email protected] (no longer a valid address... try [email protected]) are sent to both bilbrey and syroid. Wait a minute! The syroid mail has already been redirected. Now what happens?
The answer is that Sendmail makes as many passes through aliases as necessary to correctly redirect a message. Only after there are no further matches does Sendmail proceed. So mail to ols.book is delivered locally to bilbrey, and remotely to Tom.
Once /etc/aliases is saved, then type newaliases to convert the text file into the database format that Sendmail can use to quickly and efficiently direct the traffic. Forget this step, and none of your changes take effect!
Warning
Creating alias loops is a bad idea. Don't make aliases like both "george: brad" and "brad: george", although Sendmail can catch these. Loops that are incorporated into alias lists elude Sendmail, and only fail after the maximum number of hops (usually 32) has been exceeded. A lot of looped traffic hitting a mail server at once can bring it to its knees, not to mention annoy administrators at all the possible destination sites.
/etc/sendmail.cw is primarily used to identify the various aliases that the computer is known by. In the changes we've made to the default OpenLinux setup in the following listing, we've added each name that gwydion.orbdesigns.com is known by. Additionally, if your system is hosting mail for other domains, they should be listed in this file as well.
[root@gwydion /etc]# vi sendmail.cw
# sendmail.cw - include all aliases for your machine here.
# modified 20001104 bpb
gwydion.orbdesigns.com
gwydion
Access control is an important feature in Sendmail. Prior to version 8.9, Sendmail practiced general-purpose relaying. Unless specifically configured, any mail would be accepted and forwarded without checking or further ado. This behavior was a holdover from the older, small-town type of Internet that used to exist. Unfortunately, open relaying was far too friendly to the Internet's Public Enemy Number One: Spammers.
Nowadays, by default, Sendmail relays nothing. Open relaying can be enabled but is strongly discouraged. An alternate facility for creating small openings in the relay armor is created by using the FEATURE(access_db) facility. If this feature is present in the .mc file, then all that's necessary is to create a file called /etc/mail/access, and populate it with various address types and dispositions, as follows:
user@ disposition
user@host disposition
domainname disposition
###.### disposition
The disposition can be one of the following: OK, RELAY, REJECT, DISCARD, or ERRORxxx. The first four are rather self-evident, the last, "ERROR..." has a special extended format that must be used in compliance with RFC 1893 and RFC 821. We leave this to you for further research.
Two other Sendmail files that we don't discuss (for lack of time and space) are as follows:
Once Sendmail's configuration files are in place, the program is ready to run. Unlike many other pieces of server software, Sendmail is designed to do dual duty. When processing internal mail, Sendmail is called as a user process to process a single message. Additionally, Sendmail can be invoked from the command line:
[root@gwydion /etc]# sendmail syroid
This is a sendmail test message. Please forward to
[email protected] when you get this.
Thanks, .b
Terminate the message with a Ctrl + D to indicate End of File (or End of Text, depending on your orientation). Now we can check the last two entries in the mail log to see if the message was accepted and delivered (extra indenting added to improve readability):
[root@gwydion /etc]# tail -2 /var/log/mail
Nov 5 18:53:17 gwydion sendmail[2366]: SAA02366: from=bilbrey, size=75,
class=0, pri=30075, nrcpts=1,
msgid=<[email protected]>, relay=root@localhost
Nov 5 18:53:19 gwydion sendmail[2368]: SAA02366: [email protected],
ctladdr=bilbrey (500/100), delay=00:00:28, xdelay=00:00:02, mailer=esmtp,
relay=syroidmanor.com. [142.165.206.61], stat=Sent (302711 message accepted
for delivery)
The first entry at 18:53:17 shows the message was accepted into the mail queue. Two seconds later, the e-mail was sent. Note at the end of the latter log entry that the remote server has accepted the message.
If your machine isn't going to be accepting mail from other hosts, then you don't need to run it as a server. If it is, you should enable the mail daemon using COAS. That helps for starting Sendmail at the next reboot. To start Sendmail now, type /etc/rc.d/init.d/mta start. The daemon listens on the default port (25), waiting for incoming messages to be rewritten, aliased and forwarded, or delivered locally.
We've spent a lot of time manually configuring Sendmail. Webmin, the browser-based system configuration utility, has a comprehensive module that addresses Sendmail. We have held back on discussing it until this point. It is difficult to see the inter-relationships between the various configuration options without some hands-on experience with the lower levels of Sendmail. Figure 25-2 illustrates the Sendmail configuration module running in the KDE 2.0 Web Browser, Konqueror.
Figure 25-2
Webmin's Sendmail Configuration module, seen in Konqueror (KDE 2.0)
As you can see from the illustration, there are vast territories in the domain of Sendmail that we haven't charted with you. From Domain Routing and Mapping to Trusted Users, there's plenty for you to explore. What we've given you here is just barely enough to get started.
We close this section with a caution: an error in mail configuration might leave your system open to abuse by those gurus of modern marketing, the dreaded spammer. Understand the changes you make, and what consequences they have, especially in interaction with other settings already in place. Once you've got a working setup, don't overhaul it in one pass. Make incremental changes, and then confirm their actions and effects before proceeding to the next.
Additional Information
The default Sendmail configuration in OpenLinux does not support a number of features Webmin configures. This includes domain routing, relay domains, and, perversely, spam control. Once you add these features to the .mc file and regenerate it the .cf file, you can more effectively use Webmin to (re)configure Sendmail.
While Sendmail is far and away the most popular MTA by site counts, it has some stiff competition in these packages: Exim, Postfix, and qmail. Each has its features and benefits, as we'll touch on in this section. However, their adherents are united in one claim - "It's easier to configure than Sendmail!" We haven't had a chance to use these packages ourselves, but know people who strongly prefer each. In any large Linux User Group, you're likely to find one or more knowledgeable people to advise you on the features and benefits of each mailer.
"Exim is a message transfer agent (MTA) developed at the University of Cambridge for use on Unix systems connected to the Internet. It is freely available under the terms of the GNU General Public License. In style it is similar to Smail 3, but its facilities are more extensive, and in particular it has some defences against mail bombs and unsolicited junk mail in the form of options for refusing messages from particular hosts, networks, or senders. It can be installed in place of sendmail, although the configuration of exim is quite different to that of sendmail."
That introduction is found on the Exim Home Page, at http://www.exim.org/. Exim is strictly an SMTP mailer - it has none of the built-in facilities for handling message traffic using protocols like UUCP or others that Sendmail supports. The flip side of that coin is with a much smaller code base, Exim is easier to audit and is less likely to have vulnerabilities.
Written and maintained by Philip Hazel at Cambridge, Exim has modules available for filtering Windows executable virus types, as well as administrative GUI monitoring tools. At the download sites, documentation is available in PDF, Postscript, Texinfo, and HTML formats.
Postfix is a package authored and maintained by Wietse Venema, a Netherlander (now working for IBM as a researcher at the Thomas J. Watson Research Center). He has written a number of important pieces of security software, from Satan (Security Administrator Tool for Analyzing Networks) to the TCP Wrappers package used to secure many system services. Once upon a time, Postfix was known as VMailer, but due to a trademark dispute the software was renamed. The home page for Postfix can be found at http://www.postfix.org/start.html. Here you'll find a URL titled "Web sites" containing links to regional mirrors. In the author's own words:
"What is Postfix? It is Wietse Venema's attempt to provide an alternative to the widely-used Sendmail program. Sendmail is responsible for most of the e-mail delivered on the Internet. With an estimated 100 million users, that's billions of messages daily. A stunning number.
Postfix attempts to be fast, easy to administer, and secure, while at the same time being Sendmail compatible enough to not upset existing users."
The overview documentation for Postfix makes claims of dramatic performance benefits over other MTA software. Additionally, Postfix is written with an eye to security, and is licensed under the IBM Public License (see http://www.opensource.org/ and http://www.research.ibm.com/jikes/license/license3.htm for more details).
qmail is a capable, small footprint, tightly written piece of code developed by Dan Bernstein, a prolific coder. Dan has written a number of other packages that are also freely available under his very own license. This includes tcpserver, a replacement for inetd.
The main home site for qmail is found at http://www.qmail.org/top.html. Unfortunately, at the time of this writing, Dan's main pages for the product, http://cr.yp.to/qmail.html, (including the code repository) were unavailable. On the blurb page, we found the following excerpts:
"qmail is a secure, reliable, efficient, simple message transfer agent. It is meant as a replacement for the entire sendmail-binmail system on typical Internet-connected UNIX hosts.
Secure: Security isn't just a goal, but an absolute requirement. Mail delivery is critical for users; it cannot be turned off, so it must be completely secure. (This is why I started writing qmail: I was sick of the security holes in sendmail and other MTAs.)
* * *
Replacement for sendmail: qmail supports host and user masquerading, full host hiding, virtual domains, null clients, list-owner rewriting, relay control, double-bounce recording, arbitrary RFC 822 address lists, cross-host mailing list loop detection, per-recipient checkpointing, downed host backoffs, independent message retry schedules, etc. In short, it's up to speed on modern MTA features. qmail also includes a drop-in "sendmail" wrapper so that it will be used transparently by your current UAs."
The seminal paper-bound reference to configuring and administering Sendmail is Sendmail, Second Edition by Bryan Costales with Eric Allman (O'Reilly and Associates) - affectionately called the "Bat Book" in reference to the bat pictured on the front cover. It's the best, most complete title on this topic. As previously noted in the introduction to this chapter, Allman is the original author of Sendmail and remains the lead maintainer of the program's code.
Installed with OpenLinux, there's the Installation and Operation Guide (as previously noted), found at /usr/share/sendmail-8.9.3/op/op.ps.gz. There are a few terse manual pages: sendmail and aliases are the most pertinent.
Next, we have a collection of online references. We've found that the best way to "get" some of this very complex material is to read about it from a variety of sources, then meld what we learn into a some kind of coherent picture.
A good starting point in any exploration of Sendmail begins at the Web site for the Open Source version of the software: http://www.sendmail.org/. Then, from the University of Illinois at Urbana-Champaign, we found a good short tutorial on Sendmail at http://www-wsg.cso.uiuc.edu/sendmail/tutorial/. A site put up by Harker Systems http://www.harker.com/ not only sells Sendmail consulting and training services, but has a nice collection of Tips, Tricks, and References. UnixWorld Online has a tutorial on Sendmail at http://dune.mcs.kent.edu/~farrell/sa96/notes/sendmail/008.txt.html. Finally we found a useful, colloquial Sendmail Tutorial at http://blacksun.box.sk/sendmail.html.
Sendmail is a big, challenging, useful bit of coding work. In its various versions and incarnations, Sendmail touches most of the e-mail that all of us are overwhelmed with each day. It's far too big a topic to cover in this short a space, so we worked hard to provide you with enough information to get started, then go and ask intelligent questions to get yourself the rest of the way there.
Go to the Table Of Contents