sendmail Program
The following list describes some of the capabilities of the sendmail program.
sendmail can use different types of communications
protocols, such as TCP/IP and UUCP.
sendmail implements an SMTP server, message
queueing, and mailing lists.
sendmail controls name interpretation by
using a pattern-matching system that can work with the following naming conventions.
Domain-based naming convention. The domain technique separates
the issue of physical versus logical naming. For more information on domains,
refer to Mail Addresses.
Improvised techniques, such as providing network names that
appear local to hosts on other networks.
Arbitrary (older) naming syntaxes.
Disparate naming schemes.
The Solaris operating environment uses the sendmail
program as a mail router. The following list describes some of its functions.
sendmail is responsible for receiving and
delivering email messages.
sendmail is an interface between mail-reading
programs such as mail, mailx, and mailtool, and mail-transport programs such as uucp.
sendmail controls email messages that users
send.
By evaluating the recipients' addresses
By choosing an appropriate delivery program
By rewriting the addresses in a format that the delivery agent
can handle
By reformatting the mail headers as required
By finally passing the transformed message to the mail program
for delivery
For more information about the sendmail program,
refer to the following topics.
sendmail and Its Rerouting Mechanisms
The sendmail program supports three mechanisms for
mail rerouting. The mechanism that you choose depends on the type of change
that is involved.
A server change
A domain-wide change
A change for one user
Additionally, the rerouting mechanism that you choose can affect the
level of administration that is required. Consider the following options.
One rerouting mechanism is aliasing.
Aliasing can map names to addresses on a server-wide basis or a name
service-wide basis, depending on the type of file that you use.
Consider the following advantages and disadvantages of name service
aliasing.
The use of a name service alias file permits mail rerouting
changes to be administered from a single source. However, name service aliasing
can create lag time when the rerouting change is propagated.
Name service administration is usually restricted to a select
group of system administrators. A normal user would not administer this file.
Consider the following advantages and disadvantages of using a server
alias file.
By using a server alias file, rerouting can be managed by
anyone who can become root on the designated server.
Server aliasing should create little or no lag time when the
rerouting change is propagated.
The change only affects the local server, which might be acceptable
if most of the mail is sent to one server. However, if you need to propagate
this change to many mail servers, use a name service.
A normal user would not administer this change.
For more information, refer to Mail Alias Files in this
chapter. For a task map, refer to Administering Mail Alias Files (Task Map) in Chapter 22, Mail Services (Tasks).
The next mechanism is forwarding.
This mechanism permits users to administer mail rerouting. Local users
can reroute their incoming mail to the following.
Another mailbox
A different mailer
Another mail host
This mechanism is supported through the use of .forward
files. For more information about these files, refer to .forward Files
in this chapter. For a task map, refer to Administering .forward Files (Task Map) in Chapter 22, Mail Services (Tasks).
The last rerouting mechanism is inclusion.
This mechanism allows users to maintain alias lists instead of requiring root access. To provide this feature, the root
user must create an appropriate entry in the alias file on the server. After
this entry is created, the user can reroute mail as necessary. For more information
on inclusion, refer to /etc/mail/aliases File in this chapter. For
a task map, refer to Administering Mail Alias Files (Task Map) in Chapter 22, Mail Services (Tasks).
|
Previous