Mail Services Software Terminology

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

Other software components include domain names, mail addresses, mailboxes, and mail aliases.

Mail User 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.

Mail Transfer Agent

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

Mail Delivery Agent

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

Mailers

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.

Domain Names

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 with 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.

The following table shows the top-level domains.

!%@:: 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.

Mail Address

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

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

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. (This is an example and not an actual route.) If any of the mail handlers is down, 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.

Mailbox

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.

The following table shows some common naming conventions for special-purpose mailboxes.

Starting with version 8, the envelope sender for mail sent to a 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.

Mail Aliases

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.

Uses for Aliases Files

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.