In addition to the mail files and programs, many other components are required to establish a mail service. The following sections define these components and some of the terminology used to describe them.
The first section defines the terminology used when discussing the software parts of the mail delivery system. The next section focuses on the functions of the hardware systems in a mail configuration.
This section describes the software components of a mail system. Each service includes at least one of each of the following:
Mail user agent
Mail transfer agent
Mail delivery agent
The mail user agent is the program that acts as the interface between the user and mail transfer agent, such as the sendmail program. The mail user agents supplied with the Solaris operating environment are /usr/bin/mail, /usr/bin/mailx, $OPENWINHOME/bin/mailtool, and /usr/dt/bin/dtmail.
The mail transfer agent is responsible for the routing of mail messages and resolution of mail addresses. This is also known as a mail transport agent. The transfer agent for the Solaris operating environment is sendmail. The transfer agent performs these functions:
Accepts messages from the mail user agent
Resolves destination addresses
Selects a proper delivery agent to deliver the mail
Receives incoming mail from other mail transfer agents
A mail delivery agent is a program that implements a mail delivery protocol. The following mail delivery agents are provided with the Solaris operating environment:
The UUCP mail delivery agent, which uses uux to deliver mail.
The local mail delivery agent, which is mail.local in the standard Solaris release.
A mailer is a sendmail specific term. You can customize a mail delivery agent. A mailer is used by sendmail to identify a specific instance of a customized mail delivery agent or a mail transfer agent.
You need to specify at least one mailer in the sendmail.cf file of all systems in your network.
The smtp mailer uses SMTP to transfer a message. SMTP is the standard mail protocol used on the Internet. This is an example of an SMTP mail header:
To: paul@phoenix.stateu.edu From: Iggy.Ignatz@eng.acme.com |
If mail is sent between two users in the same domain, the header looks like this:
To: Irving.Who@eng.acme.com From: Iggy.Ignatz@eng.acme.com |
Use SMTP for sending mail outside your domain, especially for mailboxes that you must reach through the Internet.
The uucp-old mailer uses uux to deliver messages, but it formats headers with a domain-style address, and the To: and Cc: lines are formatted by domain, much like the SMTP headers. The uucp headers look like this:
To: paul@phoenix.stateu.com From: ignatz@eng.acme.com |
Use uucp-uudom for UUCP mail to systems that can handle and resolve domain-style names. The sender also must be able to handle domain-style names and be able to receive replies from the Internet.
The uucp-old mailer uses an exclamation point address in the headers. This is one of the original mailers. The headers look like this:
To: edu!stateu!phoenix!paul From: acme!ignatz |
You can define other mail delivery agents by providing a mailer specification in the sendmail.cf file. Additional information about mailers can be found in /usr/lib/mail/README.
A domain is a directory structure for network address naming. Electronic-mail addressing also uses domains. An email address has this format:
user@subdomain. ... .subdomain2.subdomain1.top-level-domain |
The part of the address to the left of the @ sign is the local address. The local address can contain information about:
Routing using another mail transport (for example, bob::vmsvax@gateway or smallberries%mill.uucp@gateway)
An alias (for example, iggy.ignatz)
The receiving mailer is responsible for determining what the local part of the address means.
The part of the address to the right of the @ sign shows the domain address where the local address is located. A dot separates each part of the domain address. The domain can be an organization, a physical area, or a geographic region.
Domain addresses are case insensitive. It makes no difference whether you use uppercase, lowercase, or mixed-case letters in the domain part of an address.
The order of domain information is hierarchical--the more local the address, the closer it is to the @ sign.
The larger the number of subdomains, the more detailed the information that is provided about the destination. Just as a subdirectory in a file-system hierarchy is considered to be inside the directory above, each subdomain in the mail address is considered to be inside the location to its right.
Table 1-1 shows the top-level domains.
Table 1-1 Top-level Domains
Domain |
Description |
---|---|
Com |
Commercial sites |
Edu |
Educational sites |
Gov |
United States government installations |
Mil |
United States military installations |
Net |
Networking organizations |
Org |
Other organizations |
!%@:: A Directory of Electronic Mail Addressing and Networks by Donnalyn Frey and Rick Adams (O'Reilly & Associates, Inc., 1993) contains a complete list of international top-level domain addresses; it is updated periodically.
For mail delivery, the name space domain name and the mail domain name occasionally do not match. However, the DNS domain name and the mail domain name must be identical. By default, the sendmail program strips the first component from the domain name to form the mail domain name. For example, if a NIS+ domain name were bldg5.eng.acme.com, its mail domain name would be eng.acme.com.
Although mail domain addresses are case insensitive, the name space domain name is not. For best results use lowercase characters when setting up the mail and name space domain names.
The mail address contains the name of the recipient and the system to which the mail message is delivered.
When you administer a small mail system that does not use a name service, addressing mail is easy: login names uniquely identify users.
When, however, you are administering a mail system that has more than one system with mailboxes, one or more domains, or when you have a UUCP (or other) mail connection to the outside world, mail addressing becomes more complex. Mail addresses can be route independent, route based, or a mixture of the two. Route-based addressing is based on old specifications and is not required or desired in most situations.
Route-independent addressing requires the sender of an email message to specify the name of the recipient and the final destination address. Route-independent addresses usually indicate the use of a high-speed network like the Internet. In addition, newer UUCP connections frequently use domain-style names. Route-independent addresses can have this format:
user@host.domain |
UUCP connections can use the following address format:
host.domain!user |
The increased popularity of the domain hierarchical naming scheme for computers is making route-independent addresses more common. In fact, the most common route-independent address omits the host name and relies on the domain name service to properly identify the final destination of the email message:
user@domain |
Route-independent addresses are read by searching for the @ sign, then reading the domain hierarchy from the right (the highest level) to the left (the most specific address to the right of the @ sign).
Route-based addressing requires the sender of an email message to specify the local address (typically, a user name) and its final destination, as well as the route that the message must take to reach its final destination. Route-based addresses were fairly common on UUCP networks, and have this format:
path!host!user |
Whenever you see an exclamation point as part of an email address, all (or some) of the route was specified by the sender. Route-based addresses are always read from left to right.
For example, an email address that looks like this:
venus!acme!sierra!ignatz |
means that mail sent to the user named ignatz is first sent to the system named venus, next to acme, and then to sierra. (Notice that this is an example and not an actual route.) If any of the mail handlers is out of commission, the message will be delayed or returned as undeliverable.
Mail sent through the uucp mailer is not restricted to using route-based addressing. Some uucp mailers also handle route-independent addressing.
A mailbox is a file on a mail server that is the final destination for email messages. The name of the mailbox can be the user name or a place to put mail for someone with a specific function, like the postmaster. Mailboxes are in the /var/mail/username file, which can exist either on the user's local system or on a remote mail server. In either case, the mailbox is on the system to which the mail is delivered.
Mail should always be delivered to a local file system so that the user agent can pull mail from the mail spool and store it readily in the local mailbox. Do not use NFS-mounted file systems as the destination for a user's mailbox. Specifically, do not direct mail to a mail client that is mounting the /var/mail file system from a remote server. Mail for the user, in this case, should be addressed to the mail server and not to the client host name. NFS-mounted file systems can cause problems with mail delivery and handling. Clients that NFS-mount /var/mail go into "remote mode" and should arrange to have the server send and receive mail for them.
The /etc/mail/aliases file and name services like NIS and NIS+ provide mechanisms for creating aliases for electronic mail addresses, so that users do not need to know the precise local name of a user's mailbox.
Table 1-2 shows some common naming conventions for special-purpose mailboxes.
Table 1-2 Conventions for the Format of Mailbox Names
Starting with version 8, the envelop sender for mail sent to an group alias is changed to the address expanded from the owner alias, if an owner alias exists. This change allows for any mail errors to be sent to the alias owner rather than being returned to the sender. What users will notice is that mail they send to an alias, when delivered, will look like it came from the alias owner. The following alias format will help with some of the problems associated with this change:
mygroup: :include:/pathname/mygroup.list owner-mygroup: mygroup-request mygroup-request: sandys, ignatz |
In this example, the mygroup alias is the actual mail alias for the group; the owner-mygroup alias receives error messages; and the mygroup-request alias should be used for administrative requests. This structure means that in mail sent to the mygroup alias, the envelope sender changes to mygroup-request.
An alias is an alternate name. For electronic mail, you can use aliases to assign a mailbox location or to define mailing lists.
For large sites, the mail alias typically defines the location of a mailbox. Providing a mail alias is like providing a mail stop as part of the address for an individual at a large corporation. If you do not provide the mail stop, the mail is delivered to a central address. Extra effort is required to determine where within the building the mail is to be delivered, and the possibility of error increases. For example, if two people named Kevin Smith are in the same building, only one of them will get mail.
Use domains and location-independent addresses as much as possible when you create mailing lists. To enhance portability and flexibility of alias files, make your alias entries in mailing lists as generic and system-independent as possible. For example, if you have a user named ignatz on system mars, in domain eng.acme.com, create the alias ignatz@eng instead of ignatz@mars. If user ignatz changes the name of his system but remains within the engineering domain, you do not need to update alias files to reflect the change in system name.
When creating alias entries, type one alias per line. You should have only one entry that contains the user's system name. For example, you could create the following entries for user ignatz:
ignatz: iggy.ignatz iggyi: iggy.ignatz iggy.ignatz: ignatz@mars |
You can create an alias for local names or domains. For example, an alias entry for user fred who has a mailbox on the system mars and who is in the domain planets could have this entry in the NIS+ aliases table:
fred: fred@planets |
When creating mail lists that include users outside your domain, create the alias with the user name and the domain name. For example, if you have a user named smallberries on system privet, in domain mgmt.acme.com, create the alias as smallberries@mgmt.acme.com.
The email address of the sender is now automatically translated to a fully qualified domain name when mail goes outside the user's domain.
You create mail aliases for global use in the NIS+ mail_aliases table, the NIS aliases map, or in local /etc/mail/aliases files. You can also create and administer mailing lists using the same alias files.
Depending on the configuration of your mail services, you can administer aliases by using the NIS or NIS+ name service to maintain a global aliases database or by updating all the local /etc/mail/aliases files to keep them synchronized.
Users can also create and use aliases. They can create aliases either in their local ~/.mailrc file, which only they can use, or in their local /etc/mail/aliases file, which can be used by anyone. Users cannot normally create or administer NIS or NIS+ alias files.
A mail configuration requires three elements, which can be combined on the same system or provided by separate systems:
A mail host
At least one mail server
Mail clients
When you want users to communicate with networks outside your domain, you must also add a fourth element, a mail gateway.
Figure 1-1 shows a typical electronic mail configuration, using the three basic mail elements plus a mail gateway. Each element is identified and described in the following sections.
A mail host is the machine that you designate as the main mail machine on your network. It is the machine to which other systems at the site forward mail that they cannot deliver. You designate a system as a mail host in the hosts database by adding the word mailhost to the right of the IP address in the local /etc/hosts file or in the hosts file in the name service. You must also use the main.cf file as the mail-configuration file on the mail host system.
A good candidate for mail host is a system on the local-area network that also has a modem for setting up PPP or UUCP links over telephone lines. Another good candidate is a system configured as a router from your network to the Internet global network. (See TCP/IP and Data Communications Administration Guide for more information on PPP, UUCP, and routers.) If none of the systems on your local network has a modem, designate one as the mail host.
Some sites use standalone machines that are not networked in a time-sharing configuration; that is, the standalone machine serves terminals attached to its serial ports. You can set up electronic mail for this configuration by treating the standalone system as the mail host of a one-system network.
A mailbox is a single file that contains email for a particular user. Mail is delivered to the system where the user's mailbox resides: the local machine or a remote server. A mail server is any system that maintains user mailboxes in its /var/mail directory.
The mail server routes all mail from a client. When a client sends mail, the mail server puts it in a queue for delivery. After the mail is in the queue, a user can reboot or turn off the client without losing those mail messages. When the recipient gets mail from a client, the path in the "From " line of the message contains the name of the mail server. If the recipient responds, the response goes to the user's mailbox. Good candidates for mail servers are systems that provide a home directory for users or that are backed up regularly.
If the mail server is not the user's local system, users in configurations using NFS software can mount the /var/mail directory by using the /etc/vfstab file (if they have root access) or by using the automounter. If NFS support is not available, the users can log in to the server to read their mail.
If users on your network send other types of mail, such as PostScriptTM files, audio files, or files from desktop publishing systems, you need to allocate more space on the mail server for mailboxes.
One advantage to establishing a mail server for all mailboxes is that it makes backups easy. Having mail spread over many systems makes it hard to do backups. The disadvantage of storing many mailboxes on one server is that the server can be a single point of failure for many users, but the advantages of providing good backups usually make the risk worthwhile.
A mail client is any system that receives mail on a mail server and does not have a local /var/mail directory. This is known as remote mode. Remote mode is enabled by default in /etc/mail/subsidiary.cf.
You must check that the mail client has the appropriate entry in the /etc/vfstab file and a mount point to mount the mailbox from the mail server. Also make sure that the alias for the client is directed to the mail server's host name, not to the client's.
The mail gateway is a machine that handles connections between networks running different communications protocols or communications between different networks using the same protocol. For example, a mail gateway might connect a TCP/IP network to a network running the Systems Network Architecture (SNA) protocol suite.
The simplest mail gateway to set up is one that connects two networks that use the same protocol or mailer. This system handles mail with an address for which sendmail cannot find a recipient in your domain. If a mail gateway exists, sendmail uses it for sending and receiving mail outside your domain.
You can set up a mail gateway between two networks using unmatched mailers, as shown in Figure 1-2. To support this, you must customize the sendmail.cf file on the mail gateway system, which can be a difficult and time-consuming process.
If you have to set up a mail gateway, you should find a gateway-configuration file that is close to what you need and modify it to fit your situation.
If you have a machine providing connections to the Internet, you can configure that machine as the mail gateway. Carefully consider your site's security needs before you configure a mail gateway. You might need to create a firewall gateway between your corporate network and the outside world, and set that up as the mail gateway.
Mail services include many programs and daemons that interact with each other. This section introduces the programs and the terms and concepts related to administering electronic mail. Table 1-3 shows the contents of the /usr/bin directory that are used for mail services.
Table 1-3 Contents of the /usr/bin Directory Used for Mail Services
Name |
Type |
Description |
---|---|---|
File |
A program to manipulate the NIS+ aliases map |
|
File |
A user agent |
|
File |
A filter to store mail in SunOS 4.1 mailbox format |
|
Link |
Link to /usr/lib/sendmail; used to list the mail queue |
|
File |
A program used to read mail statistics stored in the /etc/mail/sendmail.st file (if present) |
|
File |
A user agent |
|
File |
A program that connects to the mailer for address verification and debugging |
|
Link |
Link to /usr/lib/sendmail; used to create the binary form of the aliases file |
|
Link |
Link to /usr/bin/mail; command often used to permit only the sending of mail |
|
File |
A command to set up an automatic reply to mail |
Table 1-4 shows the contents of the /etc/mail directory.
Table 1-4 Contents of the /etc/mail Directory
Name |
Type |
Description |
---|---|---|
File |
Default settings for the mailtool user agent |
|
File |
Mail-forwarding information |
|
File |
Binary form of mail-forwarding information (created by running newaliases) |
|
File |
Binary form of mail-forwarding information (created by running newaliases) |
|
File |
Default settings for the mailx user agent |
|
File |
Sample configuration file for main systems |
|
File |
Contains a list of all domains for which relaying is allowed; by default, only the local domain is allowed |
|
File |
Configuration file for mail routing |
|
File |
Optional file that you can create if the number of aliases for the mail host is too long |
|
File |
Help file used by the SMTP HELP command |
|
File |
File that lists the PID of the listening daemon |
|
File |
The sendmail statistics file; if this file is present, sendmail logs the amount of traffic through each mailer |
|
File |
Stores macro and class definitions for name space lookup from sendmail.cf |
|
File |
Table 1-5 shows the contents of the /usr/lib directory that are used for mail services.
Table 1-5 Contents of the /usr/lib Directory Used for Mail Services
Name |
Type |
Description |
---|---|---|
File |
Mailer that delivers mail to mailboxes |
|
File |
The routing program, also known as the mail transfer agent |
Within the /usr/lib directory is a subdirectory that contains all of the files needed to build a sendmail.cf file. The contents of this directory are shown in Table 1-6.
Table 1-6 Contents of the /usr/lib/mail Directory Used for Mail Services
Name |
Type |
Description |
---|---|---|
README |
File |
Document describing the configuration files |
cf |
Directory |
Site-dependent and site-independent descriptions of hosts |
File |
Main configuration file |
|
File |
Contains rules for building new configuration files |
|
File |
Configuration file for hosts that NFS-mount /var/mail from another host |
|
domain |
Directory |
Site-dependent subdomain descriptions |
domain/generic.m4 |
File |
Generic domain file from Berkeley |
File |
Domain file with changes that make sendmail function like previous Solaris versions, except that relaying is disabled completely, sender addresses with no hostname are rejected, and unresolvable domains are rejected |
|
File |
Domain file with changes that make sendmail function like previous Solaris versions (default) |
|
feature |
Directory |
Definitions of specific features for particular hosts (see README for a full description of the features) |
m4 |
Directory |
Site-independent include files |
mailer |
Directory |
Definitions of mailers, which include local, smtp and uucp |
ostype |
Directory |
Definitions describing various operating system environments |
File |
Defines local mailer as mail |
|
File |
Defines local mailer as mail.local (default) |
|
sh |
Directory |
Shell scripts used by the m4 build process and migration aids |
File |
Checks permissions of :include: aliases and .forward files and their parent directory path for correct permissions |
|
File |
Verifies that sendmail is able to determine the fully qualified host name |
Several other files and directories are used by the mail services, as shown in Table 1-7.
Table 1-7 Other Files Used for Mail Services
Mail services are provided by a combination of these programs, which interact as shown by the simplified diagram in Figure 1-3.
Users send messages by using programs like mailx or mailtool. See the mailx(1) or mailtool(1) man pages for information about these programs.
The message is collected by the program that was used to generate it and is passed to the sendmail daemon. The sendmail daemon parses the addresses (divides them into identifiable segments) in the message, using information from the configuration file, /etc/mail/sendmail.cf, to determine network name syntax, aliases, forwarding information, and network topology. Using this information, sendmail determines the route a message must take to get to a recipient.
The sendmail daemon passes the message to the appropriate system. The /usr/lib/mail.local program on the local system delivers the mail to the mailbox in the /var/mail/username directory of the recipient of the message.
The recipient is notified that mail has arrived, and retrieves it using mail, mailx, mailtool, or a similar program.
The sendmail program can use different types of communications protocols, like TCP/IP and UUCP. It also implements an SMTP server, message queueing, and mailing lists. Name interpretation is controlled by a pattern-matching system that can handle both domain-based naming and improvised conventions.
The sendmail program can accept domain-based naming as well as arbitrary (older) name syntaxes--resolving ambiguities by using heuristics you specify. sendmail can also convert messages between disparate naming schemes. The domain technique separates the issue of physical versus logical naming. See the TCP/IP and Data Communications Administration Guide for a complete description of Internet domain-naming conventions.
You can handle certain special cases by improvised techniques, like providing network names that appear local to hosts on other networks.
The Solaris operating environment uses the sendmail program as a mail router. sendmail is responsible for receiving and delivering electronic mail messages. It is an interface between mail-reading programs like mail, mailx, and mailtool, and mail-transport programs like uucp. The sendmail program controls email messages that users send, evaluates the recipients' addresses, chooses an appropriate delivery program, rewrites the addresses in a format that the delivery agent can handle, reformats the mail headers as required, and finally passes the transformed message to the mail program for delivery.
Solaris releases prior to Solaris 2.4 included a binary called sendmail.mx. This program is now included in the sendmail program and the functionality is turned on by adding the dns flag to the hosts entry in /etc/nsswitch.conf. For more information, see "Setting Up DNS to Work With sendmail".
The sendmail program supports three mechanisms for mail rerouting. Which mechanism you choose depends on whether this is a server or domain-wide change, or just a change for one user. In addition, by selecting a different rerouting mechanism, you can change the level of administration required.
One rerouting mechanism is aliasing, which maps names to addresses on a server-wide or a namespace-wide basis, depending on the type of file that is used. Using a namespace alias file allows for mail rerouting changes to be administered at a single source, but there can be lag-times created when the change is propagated. Also, namespace administration is usually restricted to a select group of system administrators, so this is not a change that a normal user is able to make. Rerouting handled through a server alias file is managed by anyone who can become root on that server. Normally, there should be little or no lag-time associated with propagating the change, but the change only affects the local server. This limitation might be acceptable if most of the mail is sent to one server anyway, but trying to propagate this change to many mail servers is easier using a name service. Again, this is not a change that a user is able to administer.
The next mechanisms, forwarding and inclusion, allow users the ability to administer mail rerouting. Forwarding allows local users to reroute their incoming mail to either another mail box, a different mailer, or to another mail host. This form of mail rerouting is supported through the use of .forward files. Further information on these files can be found in ".forward Files".
The last rerouting mechanism is inclusion, which allows for alias lists to be maintained by a user instead of requiring root access. To provide this, the root user must create an appropriate entry in the alias file on the server. After this entry is created, then the user can reroute mail as needed. More information on inclusion can be found in "/etc/mail/aliases".
Figure 1-4 shows how sendmail uses aliases. Programs that read mail, like /usr/bin/mailx, can have aliases of their own, which are expanded before the message reaches sendmail. The aliases for sendmail can come from a number of name space sources (local files, NIS or NIS+). The order of the lookup is determined by the nsswitch.conf file. See the nsswitch.conf(4) man page.
The sendmail program provides the following features:
It is reliable. It is designed to correctly deliver every message. No message should ever be completely lost.
It uses existing software for delivery whenever possible.
It can be configured to handle complex environments, including multiple connections to a single network type (like with UUCP or Ethernet). sendmail checks the contents of an address as well as its syntax to determine which mailer to use.
It uses configuration files to control mail configuration instead of requiring that configuration information is compiled into the code.
Users can maintain their own mailing lists. In addition, individuals can specify their own forwarding without modifying the domain-wide alias file (typically located in the domain-wide aliases maintained by NIS or NIS+).
Each user can specify a custom mailer to process incoming mail, which can provide functions like returning an "I am on vacation" message. See the vacation(1) man page for more information.
It batches addresses to a single host to reduce network traffic.
Figure 1-5 shows how sendmail interacts with the other programs in the mail system.
The user interacts with a mail-generating and -sending program. When the mail is submitted, the mail-generating program calls sendmail, which routes the message to the correct mailers. Because some of the senders might be network servers and some of the mailers might be network clients, sendmail can be used as an Internet mail gateway.
A configuration file controls the way that sendmail performs its functions. The configuration file determines the choice of delivery agents, address rewriting rules, and the format of the mail header.
The sendmail program uses the information from the /etc/mail/sendmail.cf file to perform its functions. Each system has a default sendmail.cf file installed in the /etc/mail directory. You do not need to edit or change the default configuration file for mail servers or mail clients. The only systems that require a customized configuration file are mail hosts and mail gateways.
The Solaris operating environment provides two default configuration files in the /etc/mail directory:
A configuration file named main.cf for the system (or systems) you designate as the mail host or a mail gateway
A configuration file named subsidiary.cf (a duplicate copy of the default sendmail.cf file)
The configuration file you use on a system depends on the role the system plays in your mail service.
For mail clients or mail servers, you do not need to do anything to set up or edit the default configuration file.
To set up a mail host or gateway, copy the main.cf file and rename it sendmail.cf (in the /etc/mail directory). Then reconfigure the sendmail configuration file to set the relay mailer and relay host parameters needed for your mail configuration.
The following list describes some configuration parameters you might want to change, depending on the requirements of your site: