Each mail service uses several software components. This section describes the following software components:
The mail service uses the following agents:
Mail user agent – The program that acts as the interface between the user and the sendmail mail transfer agent. The Oracle Solaris OS supplies the /usr/bin/mail and /usr/bin/mailx mail user agents.
Mail transfer agent – Responsible for the routing of mail messages and the resolution of mail addresses. This agent is also known as a mail transport agent. The sendmail program is the default mail transfer agent for the Oracle Solaris OS. The mail transfer agent performs the following functions:
Accepts messages from the mail user agent
Resolves destination addresses
Selects a suitable delivery agent to deliver the mail
Receives incoming mail from other mail transfer agents
Local delivery agent – A program that implements a mail delivery protocol. The Oracle Solaris OS provides the mail.local and procmail local delivery agents.
Mailer is a sendmail-specific term. A mailer is used by the sendmail program to identify a specific instance of a customized local delivery agent or a customized mail transfer agent. You need to specify at least one mailer in your sendmail.cf file. The sendmail program uses the Simple Mail Transfer Protocol (SMTP) mailer. The SMTP protocol defines the following mailers:
Provides regular SMTP transfers to other servers
Provides extended SMTP transfers to other servers
Provides SMTP transfers to other servers without converting 8-bit data to MIME
Provides on-demand delivery by using the F=% mailer flag
A mailbox is a file that is the final destination for email messages. The name of the mailbox can be the user name or the identity of a specific function, such as 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 instance, the mailbox is on the system to which the mail is delivered.
Mail should always be delivered to a local file system. This practice enables the user agent to pull mail from the mail spool and store it 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 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 mail handling.
The /etc/mail/aliases file and name services such as NIS provide mechanisms for creating aliases for email addresses. Users do not need to know the precise local name of their mailboxes.
The following table shows some common naming conventions for special-purpose mailboxes.
Starting with sendmail version 8, the envelope sender for mail that is sent to a group alias was changed so that mail sent to an alias looks like the mail came from the alias owner when the mail is delivered. This change enables mail errors to be sent to the alias owner, rather than being returned to the sender. The following alias format helps with some of the problems that are associated with this change:
mygroup: :include:/pathname/mygroup.list owner-mygroup: mygroup-request mygroup-request: john, bob
In this example, the mygroup alias is the actual mail alias for the group. The owner-mygroup alias receives error messages. The mygroup-request alias should be used for administrative requests. This structure means that in the mail sent to the mygroup alias, the envelope sender changes to mygroup-request.
An alias is an alternate name that can be used to assign a mailbox location or to define mailing lists. For more information, see Task Map for Administering Mail Alias Files and Mail Alias Files.
For large sites, the mail alias typically defines the location of a mailbox. Providing a mail alias is similar to providing a room number as part of the address for an individual at a large corporation that occupies multiple rooms. If you do not provide the room number, the mail is delivered to a central address. Without a room number, extra effort is required to determine where the mail is to be delivered within the building. So, the possibility of an error increases. For example, if two people named Kevin Smith are in the same building, only one of them gets the mail. To correct the problem, each Kevin Smith should have a room number added to his address.
Use domains and location-independent addresses while creating mailing lists. To enhance the portability and flexibility of alias files, make your alias entries in mailing lists as generic and system-independent as possible. For example, you have a user who is named john on system mars, in domain example.com. Create the alias john@example instead of john@mars. If user john changes the name of his system but remains within the example domain, you do not need to update alias files to reflect the change in system name.
Avoid loops and inconsistent databases when both local and domain-wide aliases are used. Also avoid the creation of alias loops when you move a user from one system to another system.
When you create 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 john:
john: john.smith johns: john.smith john.smith: john@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 is in the domain north, could have the following entry in the NIS aliases map:
fred: fred@north
When you create mail lists that include users outside your domain, create the alias with the user name and the domain name. For example, you have a user named john on system privet, in domain example.com. Create the alias as john@example.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 can use the following methods for creating and administering mail alias files:
Create mail aliases for global use in the NIS aliases map or in local /etc/mail/aliases files. You can also create and administer mailing lists that use the same alias files.
Administer aliases by using the NIS name service to maintain a global aliases database depending on the configuration of your mail services. Otherwise, you can update all the local /etc/mail/aliases files to keep the aliases synchronized.
Create and use aliases either in your local ~/.mailrc file, which only you can use, or in your local /etc/mail/aliases file, which anyone can use. NIS alias files cannot be created or administered by a regular user.