Tải bản đầy đủ
[Chapter 9] 9.7 Mail Servers

[Chapter 9] 9.7 Mail Servers

Tải bản đầy đủ

[Chapter 9] 9.7 Mail Servers

inetd by placing the following in the inetd.conf file:
pop3

stream

tcp

nowait

root

/etc/pop3d

pop3d

This entry assumes you are using pop3d, that you placed the executable in the /etc directory, and that the
port for this daemon is identified in the /etc/services file by the name pop3. If these things aren't true, adjust
the entry accordingly.
Make sure that POP3 is actually defined in /etc/services. If it isn't, add the following line to that file:
pop3

110/tcp

# Post Office Version 3

Once the lines are added to the services file and the inetd.conf file, send a SIGHUP to inetd to force it to
read the new configuration, as in this example:
# ps -ef | grep inetd
root 109 1 0
Jun 09 ?
# kill -HUP 109

0:01 /usr/sbin/inetd -s

Now that POP3 is installed, rerun the test using telnet localhost pop-3. If the POP3 daemon answers, you're
in business. All users who have a valid user account on the system are now able to download mail via POP3
or read the mail directly on the server.

9.7.2 IMAP Server
Internet Message Access Protocol (IMAP) is an alternative to POP. It provides the same basic service as
POP and adds features to support mailbox synchronization. Mailbox synchronization is the ability to read
mail on a client or directly on the server while keeping the mailboxes on both systems completely up-todate. On an average POP server, the entire contents of the mailbox are moved to the client and either deleted
from the server or retained as if never read. Deletion of individual messages on the client is not reflected on
the server because all of the messages are treated as a single unit that is either deleted or retained after the
initial transfer of data to the client. IMAP provides the ability to manipulate individual messages on either
the client or the server and to have those changes reflected in the mailboxes of both systems.
IMAP is not a new protocol - it is about as old as POP3. Nor is IMAP completely standardized. There have
been four distinct versions of IMAP: IMAP, IMAP2, IMAP3, and the current version IMAP4. New RFCs
about IMAP are still being issued. There are currently more than 10. The fear that IMAP is still in flux and
that it is difficult to implement has discouraged some vendors, so it is not as widely implemented as POP.
This is changing, however. The growing importance of email as a means of communicating, even when
people are out of the office, increases the need for a mailbox that can be read and maintained from
anywhere. The number of IMAP implementations is rising. Sun sells one for Solaris, another comes with
Slackware 96 Linux in the /usr/sbin/imapd file, and IMAP source code can be obtained via anonymous FTP
from ftp.cac.washington.edu. We use the University of Washington source code to update IMAP on our
Linux system for the examples in this section.
Download /mail/imap.tar.Z from ftp.cac.washington.edu as a binary image. Uncompress and untar the file.
This creates a directory containing the source code and Makefile needed to build IMAP. [12] Read the
file:///C|/mynapster/Downloads/warez/tcpip/ch09_07.htm (2 of 3) [2001-10-15 09:18:34]

[Chapter 9] 9.7 Mail Servers

Makefile carefully. It supports many versions of UNIX. If you find yours listed in the Makefile, use the threecharacter operating system type listed there. For our Linux system we entered:
[12] The name of the directory tells you the current release level of the software. At this
writing it is imap-4.1.BETA.
# make lnx
If it compiles without error, as it does on our Linux system, it produces three daemons: ipop2d, ipop3d, and
imapd. We are familiar with installing POP2 and POP3. The new one is imapd. Install it in /etc/services:
imap

143/tcp

# IMAP version 4

Also add it to /etc/inetd:
imap

stream

tcp

nowait

root

/usr/sbin/imapd

imapd

Now basic IMAP service is available to every user with an account on the server.
A nice feature of the University of Washington package is that it provides implementations of POP2 and
POP3 as well as IMAP. This is important because most email clients run POP3. [13] The IMAP server can
only be accessed by an IMAP client. Installing POP2 and POP3 along with IMAP gives you the chance to
evaluate IMAP and to provide it for your adventurous users while still supporting the majority of users.
[13] The pine mail client supports IMAP.
POP and IMAP are mail access servers. There is a great deal more to configuring a complete email system,
as we will see in the next chapter.

Previous: 9.6 Managing
Distributed Servers
9.6 Managing Distributed
Servers

TCP/IP Network
Administration
Book Index

Next: 9.8 Summary
9.8 Summary

[ Library Home | DNS & BIND | TCP/IP | sendmail | sendmail Reference | Firewalls | Practical Security ]

file:///C|/mynapster/Downloads/warez/tcpip/ch09_07.htm (3 of 3) [2001-10-15 09:18:34]

file:///C|/mynapster/Downloads/warez/tcpip/ch09_08.htm

Previous: 9.7 Mail Servers

Chapter 9
Configuring Network Servers

Next: 10. sendmail

9.8 Summary
This chapter covers several important TCP/IP network services.
Network File System (NFS) is the leading TCP/IP file-sharing protocol. It allows server systems to
share directories with clients that are then used by the clients as if they were local disk drives. NFS
uses trusted hosts and UNIX UIDs and GIDs for authentication and authorization. pcnfsd provides
password-based user authentication and NFS-based printer sharing for non-UNIX clients.
NFS-based printer sharing is not the only type of printer sharing available on a TCP/IP network. It is
also possible to use the Line Printer Daemon (LPD). This software is originally from BSD UNIX but
is widely available. The lpd program reads the printer definitions from the printcap file.
Network Information Service (NIS) is a server that distributes several system administrations
databases. It allows central control of and automatic distribution of important system configuration
information.
Bootstrap Protocol provides a wide range of configuration values to its client. Each implementation
of BOOTP has a different configuration file and command syntax. The CMU BOOTP server stores
configuration parameters in the /etc/bootptab file and uses a syntax very similar to the /etc/printcap
syntax.
Dynamic Host Configuration Protocol (DHCP) extends BOOTP to provide the full set of
configuration parameters defined in the Requirements for Internet Hosts RFC. It also provides for
dynamic address allocation, which allows a network to make maximum use of a limited set of
addresses.
Large networks use distributed boot servers to avoid overloading a single server and to avoid sending
boot parameters through IP routers. The configuration files on distributed boot servers are kept
synchronized through file transfer, NFS file sharing, or the Remote File Distribution Program (rdist).
Post Office Protocol (POP) and Internet Message Access Protocol (IMAP) servers allow email to be
stored on the mail server until the user is ready to read it. In the next chapter, we take a closer look at
configuring an electronic mail system as we explore sendmail.

file:///C|/mynapster/Downloads/warez/tcpip/ch09_08.htm (1 of 2) [2001-10-15 09:18:35]

file:///C|/mynapster/Downloads/warez/tcpip/ch09_08.htm

Previous: 9.7 Mail Servers
9.7 Mail Servers

TCP/IP Network
Administration
Book Index

Next: 10. sendmail
10. sendmail

[ Library Home | DNS & BIND | TCP/IP | sendmail | sendmail Reference | Firewalls | Practical Security ]

file:///C|/mynapster/Downloads/warez/tcpip/ch09_08.htm (2 of 2) [2001-10-15 09:18:35]

[Chapter 10] sendmail

Previous: 9.8 Summary

Chapter 10

Next: 10.2 Running
sendmail as a Daemon

10. sendmail
Contents:
sendmail's Function
Running sendmail as a Daemon
sendmail Aliases
The sendmail.cf File
sendmail Configuration
Rewriting the Mail Address
Modifying a sendmail.cf File
Testing sendmail.cf
Summary
Users have a love-hate relationship with email; they love to use it, and hate when it doesn't work. It's
the system administrator's job to make sure it does work. That is the job we tackle in this chapter.
sendmail is not the only mail transport program. MMDF (Multichannel Memorandum Distribution
Facility) predates sendmail and is still used today. There are also variations of basic sendmail, such as
IDA sendmail, that are widely used. But plain sendmail is the most widely used mail transport
program, and it's the one we cover.
This entire chapter is devoted to sendmail, and an entire book is easily devoted to the subject. [1] In
part this is because of email's importance, but it is also because sendmail has a complex configuration.
[1] See sendmail, by Costales and Allman (O'Reilly & Associates), for a book-length
treatment of sendmail.
The variety of programs and protocols used for email complicates configuration and support. SMTP
sends email over TCP/IP networks. Another program sends mail between users on the same system.
Still another sends mail between systems on UUCP networks. Each of these mail systems - SMTP,
UUCP, and local mail - has its own delivery program and its own mail addressing scheme. All of this
can cause confusion for mail users and for system administrators.

file:///C|/mynapster/Downloads/warez/tcpip/ch10_01.htm (1 of 3) [2001-10-15 09:18:35]

[Chapter 10] sendmail

10.1 sendmail's Function
sendmail eliminates some of the confusion caused by multiple mail delivery programs. It does this by
routing mail for the user to the proper delivery program based on the email address. It accepts mail
from a user's mail program, interprets the mail address, rewrites the address into the proper form for
the delivery program, and routes the mail to the correct delivery program. sendmail insulates the end
user from these details. If the mail is properly addressed, sendmail will see that it is properly passed
on for delivery. Likewise, for incoming mail, sendmail interprets the address and either delivers the
mail to a user's mail program or forwards it to another system.
Figure 10.1 illustrates sendmail's special role in routing mail between the various mail programs
found on UNIX systems.
Figure 10.1: Mail is routed through sendmail

In addition to routing mail between user programs and delivery programs, sendmail:



Receives and delivers SMTP (internet) mail
Provides system-wide mail aliases, which allow mailing lists

Configuring a system to perform all of these functions properly is a complex task. In this chapter we
discuss each of these functions, look at how they are configured, and examine ways to simplify the
task. First, we'll see how sendmail is run to receive SMTP mail. Then we'll see how mail aliases are
used, and how sendmail is configured to route mail based on the mail's address.

file:///C|/mynapster/Downloads/warez/tcpip/ch10_01.htm (2 of 3) [2001-10-15 09:18:35]

[Chapter 10] sendmail

Previous: 9.8 Summary
9.8 Summary

TCP/IP Network
Administration
Book Index

Next: 10.2 Running
sendmail as a Daemon
10.2 Running sendmail as a
Daemon

[ Library Home | DNS & BIND | TCP/IP | sendmail | sendmail Reference | Firewalls | Practical Security ]

file:///C|/mynapster/Downloads/warez/tcpip/ch10_01.htm (3 of 3) [2001-10-15 09:18:35]

[Chapter 10] 10.2 Running sendmail as a Daemon

Previous: 10.1 sendmail's
Function

Chapter 10
sendmail

Next: 10.3 sendmail Aliases

10.2 Running sendmail as a Daemon
To receive SMTP mail from the network, run sendmail as a daemon during system startup. The sendmail
daemon listens to TCP port 25 and processes incoming mail. In most cases the code to start sendmail is
already in one of your boot scripts. If it isn't, add it. The following code is from the Slackware Linux
/etc/rc.d/rc.M startup script:
# Start the sendmail daemon:
if [ -x /usr/sbin/sendmail ]; then
echo "Starting sendmail daemon (/usr/sbin/sendmail -bd -q 15m)..."
/usr/sbin/sendmail -bd -q 15m
fi
First, this code checks for the existence of the sendmail program. If the program is found, the code displays
a startup message on the console and runs sendmail with two command-line options. One option, the -q
option, tells sendmail how often to process the mail queue. In the sample code, the queue is processed every
15 minutes (-q15m), which is a good setting to process the queue frequently. Don't set this time too low.
Processing the queue too often can cause problems if the queue grows very large, due to a delivery problem
such as a network outage. For the average desktop system, every hour (-q1h) or half hour (-q30m) is an
adequate setting.
The other option relates directly to receiving SMTP mail. The option (-bd) tells sendmail to run as a daemon
and to listen to TCP port 25 for incoming mail. Use this option if you want your system to accept incoming
TCP/IP mail.
The Linux example is a simple one. Some systems have a more complex startup script. Solaris 2.5, which
dedicates the entire /etc/init.d/sendmail script to starting sendmail, is a notable example. The mail queue
directory holds mail that has not yet been delivered. It is possible that the system went down while the mail
queue was being processed. Versions of sendmail prior to sendmail V8, such as the version that comes with
Solaris 2.5, create lock files when processing the queue. Therefore lock files may have been left behind
inadvertently and should be removed during the boot. Solaris checks for the existence of the mail queue
directory and removes any lock files found there. If a mail queue directory doesn't exist, it creates one. The
additional code found in some startup scripts is not required when running sendmail V8. All you really need
is the sendmail command with the -bd option.

file:///C|/mynapster/Downloads/warez/tcpip/ch10_02.htm (1 of 2) [2001-10-15 09:18:36]

[Chapter 10] 10.2 Running sendmail as a Daemon

Previous: 10.1 sendmail's
Function
10.1 sendmail's Function

TCP/IP Network
Administration

Next: 10.3 sendmail Aliases

Book Index

10.3 sendmail Aliases

[ Library Home | DNS & BIND | TCP/IP | sendmail | sendmail Reference | Firewalls | Practical Security ]

file:///C|/mynapster/Downloads/warez/tcpip/ch10_02.htm (2 of 2) [2001-10-15 09:18:36]