Provides overview information for the mail service
Provides step-by-step instructions for setting up and troubleshooting the mail service
Provides background information on the mail service
Provides information on what's new for the mail service
Setting up and maintaining an electronic mail service involves complex tasks that are critical to the daily operation of your network. As a network administrator, you might need to expand an existing mail service. Alternately, you might need to set up a mail service on a new network or a subnet. The chapters on mail services can help you plan and set up a mail service for your network. This chapter provides a list of new features in sendmail, as well as a list of other sources of information. The chapter also provides overviews of the software and hardware components that are required to establish a mail service.
Look in Chapter 22, Mail Services (Tasks) for procedural information on how to set up and administer mail services. For details, refer to Task Map for Mail Services.
Look in Chapter 23, Mail Services (Reference) for a more detailed description of the components of mail services. This chapter also describes the mail service programs and files, the mail routing process, and the interactions of sendmail with name services.
Version 8.12 of sendmail has been included in this Solaris 9 release. Chapter 24, What's New With Mail Services (Reference) describes all of its new features. The following list highlights some of the important changes to sendmail.
Chapter 24, What's New With Mail Services (Reference) also describes these other changes.
The following is a list of additional information sources about sendmail.
Costales, Bryan. sendmail, Second Edition. O'Reilly & Associates, Inc., 1997.
Home page for sendmail – http://www.sendmail.org.
FAQ for sendmail – http://www.sendmail.org/faq.
README for new sendmail configuration files – http://www.sendmail.org/m4/readme.html.
A guide for issues that are related to migrating to more recent versions of sendmail – http://www.sendmail.org/vendor/sun/.
Many software and hardware components are required to establish a mail service. The following sections give a quick introduction to these components. These sections also provide some of the terms that are used to describe the components.
The first section, Overview of the Software Components, defines the terms that are used when discussing the software parts of the mail delivery system. The next section, Overview of the Hardware Components, focuses on the functions of the hardware systems in a mail configuration.
The following table introduces some of the software components of a mail system. Refer to Software Components for a complete description of all of the software components.
Component |
Description |
---|---|
.forward files |
Files that you can set up in a user's home directory to redirect mail or to send mail to a program automatically |
mailbox |
A file on a mail server that is the final destination for email messages |
mail addresses |
Address that contains the name of the recipient and the system to which a mail message is delivered |
mail aliases |
An alternate name that is used in a mail address |
mail queue |
A collection of mail messages that needs to be processed by the mail server |
postmaster |
A special mail alias that is used to report problems and to ask questions about the mail service |
sendmail configuration file |
A file that contains all the information necessary for mail routing |
A mail configuration requires three elements, which you can combine on the same system or provide in separate systems.
A mail host – A system that is configured to handle email addresses that are difficult to resolve
A minimum of one mail server – A system that is configured to hold one or more mailboxes
Mail clients – Systems that access mail from a mail server
If users are to communicate with networks outside your domain, you must also add a fourth element, a mail gateway.
Figure 21–1 shows a typical electronic mail configuration, using the three basic mail elements plus a mail gateway.
Each element is described in detail in Hardware Components.
This chapter describes how to set up and administer mail services. If you are not familiar with administering mail services, read Chapter 21, Mail Services (Overview) for an introduction to the components of mail services. This chapter also provides a description of a typical mail service configuration, as shown in Figure 21–1. The following list can help you find groups of related procedures that are covered in this chapter.
See Chapter 23, Mail Services (Reference) for a more detailed description of the components of mail services. This chapter also describes the mail service programs and files, the mail routing process, and the interactions of sendmail with name services.
See Chapter 24, What's New With Mail Services (Reference) for a description of the new features that are included in version 8.12 of sendmail. You can also read about changes to mail.local, mailstats, and makemap. Chapter 24, What's New With Mail Services (Reference) also provides a description of a new maintenance command, editmap.
The following table refers you to other task maps that focus on a specific group of procedures.
Task |
Description |
For Instructions |
---|---|---|
Setting up mail services |
Use these procedures to set up each component of your mail service. Learn how to set up a mail server, a mail client, a mail host, a mail gateway, and a virtual host. Also, learn how to use DNS with sendmail. | |
Building a sendmail configuration file |
Use this procedure to modify your sendmail.cf file. See an example of how to enable domain masquerading. | |
Managing mail delivery with an alternate configuration |
Use this procedure to prevent mail delivery problems that can occur if the master daemon is disabled. |
Managing Mail Delivery by Using an Alternate Configuration (Task) |
Administering mail alias files |
Use these procedures to provide aliasing on your network. Learn how to manage entries in NIS+ tables. Also, learn how to set up an NIS map, a local mail alias, a keyed map file, and a postmaster alias. | |
Administering the mail queue |
Use these procedures to provide smooth queue processing. Learn how to display and move the mail queue, force mail queue processing, and run a subset of the mail queue. Also, learn how to run the old mail queue. | |
Administering .forward files |
Use these procedures to disable .forward files or change the search path of the .forward file. Also, learn how to permit users to use the .forward file by creating and populating /etc/shells. | |
Troubleshooting procedures and tips for mail services |
Use these procedures and tips to resolve problems with your mail service. Learn how to test the mail configuration, check mail aliases, test the sendmail rule sets, verify connections to other systems, and log messages. Also, learn where to look for other mail diagnostic information. |
Troubleshooting Procedures and Tips for Mail Services (Task Map) |
Resolving error messages |
Use the information in this section to resolve some mail-related error messages. |
The following list describes some concerns that should be part of your planning process.
Determine the type of mail configuration that meets your requirements. This section describes two basic types of mail configuration and briefly lists what you need to set up each configuration. If you need to set up a new mail system or if you are expanding an existing one, you might find this section useful. Local Mail Only describes the first configuration type, and Local Mail and a Remote Connection describes the second type.
As necessary, choose the systems that are to act as mail servers, mail hosts, and mail gateways.
Make a list of all the mail clients for which you are providing service and include the location of their mailboxes. This list can help you when you are ready to create mail aliases for your users.
Decide how you plan to update aliases and forward mail messages. You might set up an aliases mailbox as a place for users to send requests for mail forwarding. Users could also use this mailbox to send requests for changes to their default mail alias. If your system uses NIS or NIS+, you can administer mail forwarding, rather than requiring users to manage mail forwarding. Administering Mail Alias Files (Task Map) provides a list of tasks that are related to aliasing. Administering .forward Files (Task Map) provides a list of tasks that are related to managing .forward files.
After you have completed the planning process, set up the systems on your site to perform the functions that are described in Setting Up Mail Services (Task Map). For other task information, refer to Task Map for Mail Services.
The simplest mail configuration, as shown in Figure 22–1, is two or more workstations that are connected to one mail host. Mail is completely local. All the clients store mail on their local disks, and the clients act as mail servers. Mail addresses are parsed by using the /etc/mail/aliases files.
To set up this kind of mail configuration, you need the following.
The default /etc/mail/sendmail.cf file, which requires no editing, on each mail client system.
A server that is designated as the mail host. You can make this designation by adding mailhost.domain_name to the /etc/hosts file on the mail host. Then, if you are not running NIS or NIS+, add the mail host IP address line to the /etc/hosts file of all mail clients.
Unless you are running NIS or NIS+, you need matching /etc/mail/aliases files on any system that has a local mailbox.
Enough space in /var/mail on each mail client system to hold the mailboxes.
For task information on setting up your mail service, refer to Setting Up Mail Services (Tasks). If you are looking for a particular procedure that is related to setting up your mail service, refer to Setting Up Mail Services (Task Map).
The most common mail configuration in a small network is shown in Figure 22–2. One system includes the mail server, the mail host, and the mail gateway that provides the remote connection. Mail is distributed by using the /etc/mail/aliases files on the mail gateway. No name service is required.
In this configuration, you can assume that the mail clients mount their mail files from /var/mail on the mail host. To set up this kind of mail configuration, you need the following.
The main.cf file on the mail gateway. This file requires no editing if Mail Exchanger (MX) records are used.
The default /etc/mail/sendmail.cf file on each mail client system. This file does not require any editing.
A server that is designated as the mail host. You can make this designation by adding mailhost.domain_name to the /etc/hosts file on the mail host. Then, if you are not running NIS or NIS+, you must provide additional information. Add the IP address line for the mail host to the /etc/hosts file of every mail client.
Unless you are running NIS or NIS+, you need matching /etc/mail/aliases files on any system that has a local mailbox.
Enough space in /var/mail on the mail server to hold the client mailboxes.
For task information on setting up your mail service, refer to Setting Up Mail Services (Tasks). If you are looking for a particular procedure that is related to setting up your mail service, refer to Setting Up Mail Services (Task Map).
The following table describes the procedures for setting up mail services.
Task |
Description |
For Instructions |
---|---|---|
Setting up a mail server |
Steps to enable a server to route mail | |
Setting up a mail client |
Steps to enable a user to receive mail | |
Setting up a mail host |
Steps to establish a mail host that can resolve email addresses | |
Setting up a mail gateway |
Steps to manage communication with networks outside your domain | |
Using DNS with sendmail |
Steps to enable DNS host lookups | |
Setting up a virtual host |
Steps to assign more than one IP address to a host |
You can readily set up a mail service if your site does not provide connections to email services outside your company or if your company is in a single domain.
Mail requires two types of configurations for local mail. Refer to Figure 22–1 in Local Mail Only for a representation of these configurations. Mail requires two more configurations for communication with networks outside your domain. Refer to Figure 21–1 in Overview of the Hardware Components or Figure 22–2 in Local Mail and a Remote Connection for a representation of these configurations. You can combine these configurations on the same system or provide these configurations on separate systems. For example, if your mail host and mail server functions are on the same system, follow the directions in this section for setting up that system as a mail host. Then, follow the directions in this section for setting up the same system as a mail server.
The following procedures for setting up a mail server and mail client apply when mailboxes are NFS mounted. However, mailboxes typically are maintained in locally mounted /var/mail directories, which eliminates the need for the following procedures.
No special steps are required to set up a mail server that is only serving mail for local users. The user must have an entry in the password file or in the namespace. Also, for mail to be delivered, the user should have a local home directory for checking the ~/.forward file. For this reason, home directory servers are often set up as the mail server. Hardware Components in Chapter 23, Mail Services (Reference) provides more information about the mail server.
The mail server can route mail for many mail clients. This type of mail server must have adequate spooling space for client mailboxes.
For clients to access their mailboxes, the /var/mail directory should be available for remote mounting. Alternately, a service such as Post Office Protocol (POP) or Internet Message Access Protocol (IMAP) should be available from the server. The following task shows you how to set up a mail server by using the /var/mail directory. To provide configuration guidelines for POP or IMAP is beyond the scope of this document.
For the following task, ensure that the /etc/dfs/dfstab file shows that the /var/mail directory is exported.
Become superuser on the mail server or assume an equivalent role.
For information about roles, refer to “Using Privileged Applications” in System Administration Guide: Security Services.
Stop sendmail.
# /etc/init.d/sendmail stop |
Check if the /var/mail directory is available for remote access.
# share |
If the /var/mail directory is listed, proceed to step 5.
If the /var/mail directory is not listed or if no list appears, continue with the appropriate substep.
(Optional) If no list appears, start NFS services.
Follow the procedure, How to Set Up Automatic File-System Sharing, to use the /var/mail directory to start NFS services.
(Optional) If the /var/mail directory is not included in the list, add the directory to /etc/dfs/dfstab.
Add the following command line to the /etc/dfs/dfstab file.
share -F nfs -o rw /var/mail |
Make the file system available for mounting.
# shareall |
Ensure that your name service has been started.
(Optional) If you are running NIS, use this command.
# ypwhich |
For more information, refer to the ypwhich(1) man page.
(Optional) If you are running NIS+, use this command.
# nisls |
For more information, refer to the nisls(1) man page.
(Optional) If you are running DNS, use this command.
# nslookup hostname |
Use your host name.
For more information, refer to the nslookup(1M) man page.
(Optional) If you are running LDAP, use this command.
# ldaplist |
For more information, refer to the ldaplist(1) man page.
Restart sendmail.
# /etc/init.d/sendmail start |
The mail.local program automatically creates mailboxes in the /var/mail directory the first time a message is delivered. You do not need to create individual mailboxes for your mail clients.
A mail client is a user of mail services with a mailbox on a mail server. Additionally, the mail client has a mail alias in the /etc/mail/aliases file that points to the location of the mailbox. Hardware Components in Chapter 23, Mail Services (Reference) provides a brief description of a mail client.
You can also perform the task of setting up a mail client by using a service such as Post Office Protocol (POP) or Internet Message Access Protocol (IMAP). However, to provide configuration guidelines for POP or IMAP is beyond the scope of this document.
Become superuser on the mail client's system or assume an equivalent role.
For information about roles, refer to “Using Privileged Applications” in System Administration Guide: Security Services.
Stop sendmail.
# /etc/init.d/sendmail stop |
Ensure that a /var/mail mount point exists on the mail client's system.
The mount point should have been created during the installation process. You can use ls to ensure that the file system exists. The following example shows the response that you receive if the file system has not been created.
# ls -l /var/mail /var/mail not found |
Ensure that no files are in the /var/mail directory.
If mail files do exist in this directory, you should move them so that they are not covered when the /var/mail directory is mounted from the server.
Mount the /var/mail directory from the mail server.
You can mount the mail directory automatically or at boot time.
(Optional) Mount /var/mail automatically.
Add an entry such as the following to the /etc/auto_direct file.
/var/mail -rw,hard,actimeo=0 server:/var/mail |
Use the assigned server name.
(Optional) Mount /var/mail at boot time.
Add the following entry to the /etc/vfstab file. This entry permits the /var/mail directory on the mail server that is specified to mount the local /var/mail directory.
server:/var/mail - /var/mail nfs - no rw,hard,actimeo=0 |
The client's mailbox is automatically mounted whenever the system is rebooted. If you are not rebooting the system, type the following command to mount the client mailbox.
# mountall |
For mailbox locking and mailbox access to work properly, you must include the actimeo=0 option when mounting mail from an NFS server.
Update /etc/hosts.
Edit the /etc/hosts file and add an entry for the mail server. This step is not required if you are using a name service.
# cat /etc/hosts # # Internet host table # .. IP_address mailhost mailhost mailhost.example.com |
Use the assigned IP addresses.
Use the assigned domain.
Use the assigned mailhost.
For more information, refer to the hosts(4) man page.
Add an entry for the client to one of the alias files.
Refer to Administering Mail Alias Files (Task Map) for a task map about administering mail alias files.
The mail.local program automatically creates mailboxes in the /var/mail directory the first time a message is delivered. You do not need to create individual mailboxes for your mail clients.
Restart sendmail.
# /etc/init.d/sendmail start |
A mail host resolves email addresses and reroutes mail within your domain. A good candidate for a mail host is a system that provides your network with a remote connection or connects your network to a parent domain. The following procedure shows you how to set up a mail host.
Become superuser on the mail host system or assume an equivalent role.
For information about roles, refer to “Using Privileged Applications” in System Administration Guide: Security Services.
Stop sendmail.
# /etc/init.d/sendmail stop |
Verify the host-name configuration.
Run the check-hostname script to verify that sendmail can identify the fully qualified host name for this server.
% /usr/lib/mail/sh/check-hostname hostname phoenix OK: fully qualified as phoenix.example.com |
If this script is not successful in identifying the fully qualified host name, you need to add the fully qualified host name as the first alias for the host in /etc/hosts.
Update the /etc/hosts file.
Choose the step that is appropriate for you.
(Optional) If you are using NIS or NIS+, edit the /etc/hosts file on the system that is to be the new mail host.
Add the word mailhost and mailhost.domain after the IP address and system name of the mail host system.
IP_address mailhost mailhost mailhost.domain loghost |
Use the assigned IP address.
Use the system name of the mail host system.
Use the expanded domain name.
The system is now designated as a mail host. The domain should be identical to the string that is given as the subdomain name in the output of the following command.
% /usr/lib/sendmail -bt -d0 </dev/null Version 8.12.0+Sun Compiled with: LDAPMAP MAP_REGEX LOG MATCHGECOS MIME7TO8 MIME8TO7 NAMED_BIND NDBM NETINET NETINET6 NETUNIX NEWDB NIS NISPLUS QUEUE SCANF SMTP USERDB XDEBUG ============ SYSTEM IDENTITY (after readcf) ============ (short domain name) $w = phoenix (canonical domain name) $j = phoenix.example.com (subdomain name) $m = example.com (node name) $k = phoenix ======================================================== |
See the following example of how the hosts file should look after these changes.
# cat /etc/hosts # # Internet host table # 172.31.255.255 localhost 192.168.255.255 phoenix mailhost mailhost.example.com loghost |
(Optional) If you are not using NIS or NIS+, edit the /etc/hosts file on each system in the network. Create the following entry.
IP_address mailhost mailhost mailhost.domain loghost |
Select the correct configuration file to copy and rename.
The following command copies and renames the /etc/mail/main.cf file.
# cp /etc/mail/main.cf /etc/mail/sendmail.cf |
Restart sendmail.
# /etc/init.d/sendmail start |
Test your mail configuration.
See How to Test the Mail Configuration for instructions.
For further information about mail hosts, refer to Hardware Components in Chapter 23, Mail Services (Reference).
A mail gateway manages communication with networks outside your domain. The mailer on the sending mail gateway can match the mailer on the receiving system.
A good candidate for a mail gateway is a system that is attached to Ethernet and phone lines. Another good candidate is a system that is configured as a router to the Internet. You can configure the mail host or another system as the mail gateway. You might choose to configure more than one mail gateway for your domain. If you have UNIX-to-UNIX Copy Program (UUCP) connections, you should configure the system (or systems) with UUCP connections as the mail gateway.
Become superuser on the mail gateway or assume an equivalent role.
For information about roles, refer to “Using Privileged Applications” in System Administration Guide: Security Services.
Stop sendmail.
# /etc/init.d/sendmail stop |
Select the correct configuration file to copy and rename.
The following command copies and renames the main.cf file.
# cp /etc/mail/main.cf /etc/mail/sendmail.cf |
Verify the host-name configuration.
Run the check-hostname script to verify that sendmail can identify the fully qualified host name for this server.
# /usr/lib/mail/sh/check-hostname hostname phoenix OK: fully qualified as phoenix.example.com |
If this script is not successful in identifying the fully qualified host name, you need to add the fully qualified host name as the first alias for the host in /etc/hosts. If you need help with this step, refer to Step 4 of How to Set Up a Mail Host.
Ensure that your name service has been started.
(Optional) If you are running NIS, use this command.
# ypwhich |
For more information, refer to the ypwhich(1) man page.
(Optional) If you are running NIS+, use this command.
# nisls |
For more information, refer to the nisls(1) man page.
(Optional) If you are running DNS, use this command.
# nslookup hostname |
Use your host name.
For more information, refer to the nslookup(1M) man page.
(Optional) If you are running LDAP, use this command.
# ldaplist |
For more information, refer to the ldaplist(1) man page.
Restart sendmail.
# /etc/init.d/sendmail start |
Test your mail configuration
See How to Test the Mail Configuration for instructions.
For more information about the mail gateway, refer to Hardware Components in Chapter 23, Mail Services (Reference).
The DNS name service does not support aliases for individuals. This name service does support aliases for hosts or domains that use Mail Exchanger (MX) records and CNAME records. You can specify host names, domain names, or both names in the DNS database. For more information about sendmail and DNS, see Interactions of sendmail With Name Services in Chapter 23, Mail Services (Reference), or see the System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP).
Become superuser or assume an equivalent role.
For information about roles, refer to “Using Privileged Applications” in System Administration Guide: Security Services.
Enable DNS host lookups (NIS+ only).
Edit the /etc/nsswitch.conf file and remove the # from the hosts definition that includes the dns flag. The host entry must include the dns flag, as the following example shows, in order for the DNS host aliases to be used.
# grep hosts /etc/nsswitch.conf #hosts: nisplus [NOTFOUND=return] files hosts: dns nisplus [NOTFOUND=return] files |
Check for a mailhost and mailhost.domain entry.
Use nslookup to ensure that an entry exists for mailhost and mailhost.domain in the DNS database. For more information, refer to the nslookup(1M) man page.
If you need to assign more than one IP address to a host, see this Web site: http://www.sendmail.org/virtual-hosting.html. This site provides complete instructions on how to use sendmail to set up a virtual host. However, in the “Sendmail Configuration” section, do not perform step 3b, as shown in the following.
# cd sendmail-VERSION/cf/cf # ./Build mailserver.cf # cp mailserver.cf /etc/mail/sendmail.cf |
Instead, for the Solaris operating environment, perform the following steps.
# cd /usr/lib/mail/cf # /usr/ccs/bin/make mailserver.cf # cp mailserver.cf /etc/mail/sendmail.cf |
Use the name of the .cf file.
Building the sendmail.cf Configuration File (Task) outlines the same three steps as part of the build process.
After you have generated your /etc/mail/sendmail.cf file, you can continue with the next steps to create a virtual user table.
How to Build a New sendmail.cf File shows you how to build the configuration file. Although you can still use older versions of sendmail.cf files, the best practice is to use the new format.
For more details, you should read from the following resources.
/usr/lib/mail/README provides a complete description of the configuration process.
http://www.sendmail.org provides online information about sendmail configuration.
Versions of the Configuration File and sendmail Configuration File, in Chapter 23, Mail Services (Reference), also provide some guidance.
The following sections in Chapter 24, What's New With Mail Services (Reference) identify new m4 configuration features.
The following procedure shows you how to build a new configuration file.
/usr/lib/mail/cf/main-v7sun.mc is now /usr/lib/mail/cf/main.mc.
Become superuser or assume an equivalent role.
For information about roles, refer to “Using Privileged Applications” in System Administration Guide: Security Services.
Stop sendmail.
# /etc/init.d/sendmail stop |
Make a copy of the configuration files that you are changing.
# cd /usr/lib/mail/cf # cp main.mc myhost.mc |
Select a new name for your .mc file.
Edit the new configuration files (for example, myhost.mc), as necessary.
For example, add the following command line to enable domain masquerading.
# cat myhost.mc .. MASQUERADE_AS(`host.domain') |
Use the desired host name and domain name.
In this example, MASQUERADE_AS causes sent mail to be labeled as originating from host.domain, rather than $j.
Build the configuration file by using m4.
# /usr/ccs/bin/make myhost.cf |
Test the new configuration file by using the -C option to specify the new file.
# /usr/lib/sendmail -C myhost.cf -v testaddr </dev/null |
While this command displays messages, it sends a message to testaddr. Only outgoing mail can be tested without restarting the sendmail service on the system. For systems that are not handling mail yet, use the full testing procedure in How to Test the Mail Configuration.
Install the new configuration file after making a copy of the original.
# cp /etc/mail/sendmail.cf /etc/mail/sendmail.cf.save # cp myhost.cf /etc/mail/sendmail.cf |
Restart the sendmail service.
# /etc/init.d/sendmail start |
To facilitate the transport of inbound mail and outbound mail, the new default configuration of sendmail uses a daemon and a client queue runner. If you have disabled your daemon, you should perform the following task. For a detailed explanation, refer to New Configuration File, submit.cf.
In the default configuration of sendmail, the client queue runner must be able to submit mail to the daemon on the local SMTP port. If the daemon is not listening on the SMTP port, the mail remains in the queue. To avoid this problem, perform the following task. For more information about the daemon and client queue runner and to understand why you might have to use this alternate configuration, refer to New Configuration File, submit.cf.
This procedure ensures that your daemon runs only to accept connections from the local host.
Become superuser or assume an equivalent role.
For information about roles, refer to “Using Privileged Applications” in System Administration Guide: Security Services.
Stop sendmail.
# /etc/init.d/sendmail stop |
Make a copy of the configuration file that you are changing. You could copy either subsidiary.mc or main.mc, depending on your requirements. In this example, the subsidiary.mc file is used.
# cd /usr/lib/mail/cf # cp subsidiary.mc myhost.mc |
Select a new name for your .mc file.
Edit the new configuration file (for example, myhost.mc).
Add the following line before the MAILER() lines.
# cat myhost.mc .. DAEMON_OPTIONS(`NAME=NoMTA4, Family=inet, Addr=127.0.0.1')dnl |
(Optional) If your host has an IPv6 local host address that is enabled, edit the new configuration file as follows.
Add both of the following lines before the MAILER() lines.
# cat myhost.mc .. DAEMON_OPTIONS(`NAME=NoMTA4, Family=inet, Addr=127.0.0.1')dnl DAEMON_OPTIONS(`NAME=NoMTA6, Family=inet6, Addr=::1')dnl |
(Optional) To see if your host has an IPv6 local host address that is enbled, run the following command.
# /usr/sbin/ifconfig -a |
If IPv6 is enabled, you should see output that is similar to the following.
lo0: flags=2000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv6> mtu 8252 index 1 inet6 ::1/128 |
Build the configuration file by using m4.
# /usr/ccs/bin/make myhost.cf |
Install the new configuration file after making a copy of the original.
# cp /etc/mail/sendmail.cf /etc/mail/sendmail.cf.save # cp myhost.cf /etc/mail/sendmail.cf |
Restart the sendmail service.
# /etc/init.d/sendmail start |
The following table describes the procedures for administering mail alias files. For more information on this topic, refer to Mail Alias Files in Chapter 23, Mail Services (Reference).
Task |
Description |
For Instructions |
---|---|---|
Managing alias entries in an NIS+ mail_aliases table |
If your name service is NIS+, use these procedures to manage the contents of your mail_aliases table. Learn how to list, add, edit, and delete entries. | |
Setting up an NIS mail.aliases map |
If your name service is NIS, follow these instructions to facilitate aliasing with a mail.aliases map. | |
Setting up a local mail alias file |
If you are not using a name service (such as NIS or NIS+), follow these instructions to facilitate aliasing with the /etc/mail/aliases file. | |
Creating a keyed map file |
Use these steps to facilitate aliasing with a keyed map file. | |
Setting up the postmaster alias |
Use the procedures in this section to manage the postmaster alias. You must have this alias. |
Mail aliases must be unique within the domain. This section provides the procedures for administering mail alias files. Alternately, you can use the AdminTool's Database Manager application to perform these tasks on the aliases database.
In addition, you can create database files for the local mail host by using makemap. Refer to the makemap(1M) man page. The use of these database files does not provide all of the advantages of using a name service such as NIS or NIS+. However, you should be able to retrieve the data from these local database files faster because no network lookups are involved. For more information, refer to Interactions of sendmail With Name Services and Mail Alias Files in Chapter 23, Mail Services (Reference).
To manage entries in an NIS+ table, you can use the aliasadm command. To list, add, modify, or delete table entries with the aliasadm command, you begin a particular task with the following steps.
Either be a member of the NIS+ group that owns the table, or become root on the mail server, or assume an equivalent role.
For information about roles, refer to “Using Privileged Applications” in System Administration Guide: Security Services.
Complete your task by following the instructions from the example that meets your requirements.
Example—Listing the Entire Contents of the NIS+ mail_aliases Table
Example—Listing an Individual Entry From the NIS+ mail_aliases Table
Example—Listing Partial Matches From the NIS+ mail_aliases Table
Example—Adding Aliases to the NIS+ mail_aliases Table From the Command Line
Example—Adding Entries by Editing an NIS+ mail_aliases Table
In some instances, you should begin the task by compiling a list of each of your mail clients, the locations of their mailboxes, and the names of the mail server systems.
To create a table, follow these instructions.
Either be a member of the NIS+ group that owns the table, or become root on the mail server, or assume an equivalent role.
For information about roles, refer to “Using Privileged Applications” in System Administration Guide: Security Services.
Initiate an NIS+ table.
# aliasadm -I |
Add entries to the table.
To add two or three aliases, refer to Example—Adding Aliases to the NIS+ mail_aliases Table From the Command Line.
To add more than two or three aliases, refer to Example—Adding Entries by Editing an NIS+ mail_aliases Table.
For more information, refer to the aliasadm(1M) man page.
To see a complete list of the contents of the table, follow these instructions.
Either be a member of the NIS+ group that owns the table, or become root on the mail server, or assume an equivalent role.
For information about roles, refer to “Using Privileged Applications” in System Administration Guide: Security Services.
List all of the entries in alphabetical order by alias.
# aliasadm -1 |
For more information, refer to the aliasadm(1M) man page.
To see an individual entry from the table, follow these instructions.
Either be a member of the NIS+ group that owns the table, or become root on the mail server, or assume an equivalent role.
For information about roles, refer to “Using Privileged Applications” in System Administration Guide: Security Services.
List an individual entry.
# aliasadm -m ignatz ignatz: ignatz@saturn # Alias for Iggy Ignatz |
The command matches only the complete alias name, not partial strings. You cannot use metacharacters, such as * and ?, with aliasadm -m.
For more information, refer to the aliasadm(1M) man page.
To see partial matches from the table, follow these instructions.
Either be a member of the NIS+ group that owns the table, or become root on the mail server, or assume an equivalent role.
For information about roles, refer to “Using Privileged Applications” in System Administration Guide: Security Services.
List partial matches from the table.
# aliasadm -l | grep partial_string |
Use the string of your choice for your search.
For more information, refer to the aliasadm(1M) man page.
To add two or three aliases to the table, follow these instructions.
Compile a list of each of your mail clients, the locations of their mailboxes, and the names of the mail server systems.
Either be a member of the NIS+ group that owns the table, or become root on the mail server, or assume an equivalent role.
For information about roles, refer to “Using Privileged Applications” in System Administration Guide: Security Services.
(Optional) If necessary, initiate an NIS+ table.
If you are creating a completely new NIS+ mail_aliases table, you must first initiate the table. To complete this task, refer to Example—Initiating an NIS+ mail_aliases Table.
Add aliases to the table.
See this example of a typical entry.
# aliasadm -a iggy iggy.ignatz@saturn "Iggy Ignatz" |
The following list describes the input from the preceding example.
The option for adding an alias
The short form of the alias name
The expanded alias name
The name for the alias in quotation marks
Display the entry that you created and ensure that the entry is correct.
# aliasadm -m alias |
The entry that you created
For more information, refer to the aliasadm(1M) man page.
To add more than two or three aliases to the table, follow these instructions.
Compile a list of each of your mail clients, the locations of their mailboxes, and the names of the mail server systems.
Either be a member of the NIS+ group that owns the table, or become root on the mail server, or assume an equivalent role.
For information about roles, refer to “Using Privileged Applications” in System Administration Guide: Security Services.
Display and edit the aliases table.
# aliasadm -e |
This command displays the table and enables you to edit the table. The editor that you use has been set with the $EDITOR environment variable. If this variable is not set, vi is the default editor.
Use the following format to type each alias on a separate line.
alias: expanded_alias # ["option" # "comments"] |
This column is for the short form of the alias name.
This column is for the expanded alias name.
This column is reserved for future use.
This column is used for comments about the individual alias, such as a name for the alias.
If you leave the option column blank, type an empty pair of quotation marks ("") and add the comments.
The order of the entries is not important to the NIS+ mail_aliases table. The aliasadm -l command sorts the list and displays the entries in alphabetical order.
For more information, refer to Mail Alias Files and the aliasadm(1M) man page.
To edit entries in the table, follow these instructions.
Either be a member of the NIS+ group that owns the table, or become root on the mail server, or assume an equivalent role.
For information about roles, refer to “Using Privileged Applications” in System Administration Guide: Security Services.
Display the alias entry.
# aliasadm -m alias |
Use the assigned alias name.
Edit the alias entry, as necessary.
# aliasadm -c alias expanded_alias [options comments] |
If necessary, edit the alias name.
If necessary, edit the expanded alias name.
If necessary, edit the option.
If necessary, edit the comment for this entry.
For more information, refer to the aliasadm(1M) man page, as well as Mail Alias Files.
Display the entry that you have edited and ensure that the entry is correct.
# aliasadm -m alias |
For more information, refer to the aliasadm(1M) man page.
To delete entries from the table, follow these instructions.
Either be a member of the NIS+ group that owns the table, or become root on the mail server, or assume an equivalent role.
For information about roles, refer to “Using Privileged Applications” in System Administration Guide: Security Services.
Delete an entry from the table.
# aliasadm -d alias |
Use the alias name for the entry that you are deleting.
For more information, refer to the aliasadm(1M) man page.
Use the following procedure to facilitate aliasing with an NIS mail.aliases map.
Compile a list of each of your mail clients, the locations of their mailboxes, and the names of the mail server systems.
Become root on the NIS master server or assume an equivalent role.
For information about roles, refer to “Using Privileged Applications” in System Administration Guide: Security Services.
Edit the /etc/mail/aliases file, and make the following entries.
Add an entry for each mail client.
# cat /etc/mail/aliases .. alias:expanded_alias |
Use the short alias name.
Use the expanded alias name (user@host.domain.com).
Ensure that you have a Postmaster: root entry.
# cat /etc/mail/aliases .. Postmaster: root |
Add an alias for root. Use the mail address of the person who is designated as the postmaster.
# cat /etc/mail/aliases .. root: user@host.domain.com |
Use the assigned address of the designated postmaster.
Ensure that the NIS master server is running a name service to resolve the host names on each mail server.
Change to the /var/yp directory.
# cd /var/yp |
Apply the make command.
# make |
The changes in the /etc/hosts and /etc/mail/aliases files are propagated to NIS slave systems. The changes are active in only a few minutes, at most.
Use the following procedure to resolve aliases with a local mail alias file.
Compile a list of each of your users and the locations of their mailboxes.
Become root on the mail server or assume an equivalent role.
For information about roles, refer to “Using Privileged Applications” in System Administration Guide: Security Services.
Edit the /etc/mail/aliases file and make the following entries.
Add an entry for each user.
user1: user2@host.domain |
Use the new alias name.
Use the actual address for the new alias.
Ensure that you have a Postmaster: root entry.
# cat /etc/mail/aliases .. Postmaster: root |
Add an alias for root. Use the mail address of the person who is designated as the postmaster.
# cat /etc/mail/aliases .. root: user@host.domain.com |
Use the assigned address of the designated postmaster.
Rebuild the alias database.
# newaliases |
The configuration of the AliasFile option in /etc/mail/sendmail.cf determines whether this command generates in binary form either the single file, /etc/mail/aliases.db, or the pair of files, /etc/mail/aliases.dir and /etc/mail/aliases.pag.
Perform one of the following steps to copy the file or files that were generated.
(Optional) Copy the /etc/mail/aliases, the /etc/mail/aliases.dir, and the/etc/mail/aliases.pag files to each of the other systems.
You can copy the three files by using the rcp or rdist commands. Refer to the rcp(1) man page or the rdist(1) man page for more information. Alternately, you can create a script for this purpose.
When you copy these files, you do not need to run the newaliases command on each of the other systems. However, remember that you must update all the /etc/mail/aliases files each time you add or remove a mail client.
(Optional) Copy the /etc/mail/aliases.db file to each of the other systems.
You can copy the file by using the rcp or rdist commands. Refer to the rcp(1) man page or the rdist(1) man page for more information. Alternately, you can create a script for this purpose.
When you copy this file, you do not need to run the newaliases command on each of the other systems. However, remember that you must update all the /etc/mail/aliases files each time you add or remove a mail client.
To create a keyed map file, follow these instructions.
Become superuser on the mail server or assume an equivalent role.
For information about roles, refer to “Using Privileged Applications” in System Administration Guide: Security Services.
Create an input file.
Entries can have the following syntax.
old_name@newdomain.com new_name@newdomain.com old_name@olddomain.com error:nouser No such user here @olddomain.com %1@newdomain.com |
Use the user name that was previously assigned with the domain that is newly assigned.
Use the address that is newly assigned.
Use the user name that was previously assigned with the domain that was previously assigned.
Use the domain that was previously assigned.
Use the domain that is newly assigned.
The first entry redirects mail to a new alias. The next entry creates a message when an incorrect alias is used. The last entry redirects all incoming mail from olddomain to newdomain.
Create the database file.
# /usr/sbin/makemap maptype newmap < newmap |
Select a database type, such as dbm, btree, or hash.
Use the name of the input file and the first part of the name of the database file. If the dbm database type is selected, then the database files are created by using a .pag and a .dir suffix. For the other two database types, the file name is followed by .db.
Every system must be able to send mail to a postmaster mailbox. You can create an NIS or NIS+ alias for postmaster, or you can create the alias in each local /etc/mail/aliases file. Refer to these procedures.
How to Create a postmaster Alias in Each Local /etc/mail/aliases File
How to Add the postmaster Mailbox to the Aliases in the /etc/mail/aliases File
If you are creating the postmaster alias in each local /etc/mail/aliases file, follow these instructions.
Become superuser on each local system or assume an equivalent role.
For information about roles, refer to “Using Privileged Applications” in System Administration Guide: Security Services.
View the /etc/mail/aliases entry.
# cat /etc/mail/aliases # Following alias is required by the mail protocol, RFC 2821 # Set it to the address of a HUMAN who deals with this system's # mail problems. Postmaster: root |
Edit each system's /etc/mail/aliases file.
Change root to the mail address of the person who is designated as the postmaster.
Postmaster: mail_address |
Use the assigned address for the person who is designated as the postmaster.
(Optional) Create a separate mailbox for the postmaster.
You can create a separate mailbox for the postmaster to keep postmaster mail separate from personal mail. If you create a separate mailbox, use the mailbox address instead of the postmaster's personal mail address when you edit the /etc/mail/aliases files. For details, refer to How to Create a Separate Mailbox for postmaster.
If you are creating a separate mailbox for postmaster, follow these instructions.
Become root on the mail server or assume an equivalent role.
For information about roles, refer to “Using Privileged Applications” in System Administration Guide: Security Services.
Create a user account for the person who is designated as postmaster. Put an asterisk (*) in the password field.
For details about adding a user account, refer to “Managing User Accounts and Groups (Tasks)” in System Administration Guide: Basic Administration.
After mail has been delivered, enable the mail program to read and write to the mailbox name.
# mail -f postmaster |
Use the assigned address.
If you are adding a postmaster mailbox to the aliases in the /etc/mail/aliases file, follow these instructions.
Become root on each system or assume an equivalent role.
For information about roles, refer to “Using Privileged Applications” in System Administration Guide: Security Services.
Add an alias for root. Use the mail address of the person who is designated as the postmaster.
# cat /etc/mail/aliases .. root: user@host.domain.com |
Use the assigned address of the person who is designated as postmaster.
On the postmaster's local system, create an entry in the /etc/mail/aliases file that defines the name of the alias. sysadmin is an example. Also, include the path to the local mailbox.
# cat /etc/mail/aliases .. sysadmin: /usr/somewhere/somefile |
Create a name for a new alias.
Use the path to the local mailbox.
Rebuild the alias database.
# newaliases |
The following table describes the procedures for administering the mail queue.
Task |
Description |
For Instructions |
---|---|---|
Displaying the contents of the mail queue, /var/spool/mqueue |
Use this procedure to see how many messages are in the queue and how fast the messages are being cleared from the queue. |
How to Display the Contents of the Mail Queue, /var/spool/mqueue |
Forcing mail queue processing for the mail queue, /var/spool/mqueue |
Use this procedure to process messages to a system that previously was unable to receive messages. |
How to Force Mail Queue Processing in the Mail Queue, /var/spool/mqueue |
Running a subset of the mail queue, /var/spool/mqueue |
Use this procedure to force a substring of an address, such as a host name, to be processed. Also, use this procedure to force a particular message out of the queue. | |
Moving the mail queue, /var/spool/mqueue |
Use this procedure to move the mail queue. | |
Running the old mail queue, /var/spool/omqueue |
Use this procedure to run an old mail queue. |
This section describes some helpful tasks for queue administration. For information about the client-only queue, refer to New Configuration File, submit.cf. For other related information, you can refer to New Queue Features.
Use this procedure to see how many messages are in the queue and how fast they are being cleared from the queue.
Use the following command to display this information.
The queue IDs
The size of the message
The date that the message entered the queue
The message status
The sender and the recipients
# /usr/bin/mailq | more |
This command now checks for the authorization attribute, solaris.admin.mail.mailq. If the check is successful, the equivalent of specifying the -bp flag with sendmail is executed. If the check fails, an error message is printed. By default, this authorization attribute is enabled for all users. The authorization attribute can be disabled by modifying the user entry in prof_attr. For more information, refer to the man pages for prof_attr(4) and mailq(1).
Use this procedure, for example, to process messages to a system that was previously unable to receive messages.
Become root or assume an equivalent role.
For information about roles, refer to “Using Privileged Applications” in System Administration Guide: Security Services.
Force queue processing and display the progress of the jobs as the queue is cleared.
# /usr/lib/sendmail -q -v |
Use this procedure, for example, to force a substring of an address, such as a host name, to be processed. Also, use this procedure to force a particular message from the queue.
Become root or assume an equivalent role.
For information about roles, refer to “Using Privileged Applications” in System Administration Guide: Security Services.
Run a subset of the mail queue at any time with -qRstring.
# /usr/lib/sendmail -qRstring |
Use a recipient's alias or a substring of user@host.domain, such as a host name.
Alternately, you can run a subset of the mail queue with -qInnnnn.
# /usr/lib/sendmail -qInnnnn |
Use a queue ID.
If you are moving the mail queue, follow these instructions.
Become root on the mail host or assume an equivalent role.
For information about roles, refer to “Using Privileged Applications” in System Administration Guide: Security Services.
Kill the sendmail daemon.
# /etc/init.d/sendmail stop |
Now, sendmail is no longer processing the queue directory.
Change to the /var/spool directory.
# cd /var/spool |
Move the directory, mqueue, and all its contents to the omqueue directory. Then create a new empty directory that is named mqueue.
# mv mqueue omqueue; mkdir mqueue |
Set the permissions of the directory to read/write/execute by owner, and read/execute by group. Also, set the owner and group to daemon.
# chmod 750 mqueue; chown root:bin mqueue |
Start sendmail.
# /etc/init.d/sendmail start |
To run an old mail queue, follow these instructions.
Become root or assume an equivalent role.
For information about roles, refer to “Using Privileged Applications” in System Administration Guide: Security Services.
Run the old mail queue.
# /usr/lib/sendmail -oQ/var/spool/omqueue -q |
The -oQ flag specifies an alternate queue directory. The -q flag says to run every job in the queue. Use the -v flag if you are displaying the verbose output on the screen.
Remove the empty directory.
# rmdir /var/spool/omqueue |
The following table describes the procedures for administering .forward files. For more information, refer to .forward Files in Chapter 23, Mail Services (Reference).
Task |
Description |
For Instructions |
---|---|---|
Disabling .forward files |
Use this procedure if, for example, you want to prevent automated forwarding. | |
Changing the .forward file search path |
Use this procedure if, for example, you want to move all .forward files into a common directory. | |
Creating and populating /etc/shells |
Use this procedure to enable users to use the .forward file to forward mail to a program or to a file. |
This section contains several procedures that are related to .forward file administration. Because these files can be edited by users, the files can cause problems. For more information, refer to .forward Files in Chapter 23, Mail Services (Reference).
This procedure, which prevents automated forwarding, disables the .forward file for a particular host.
Become root or assume an equivalent role.
For information about roles, refer to “Using Privileged Applications” in System Administration Guide: Security Services.
Make a copy of /usr/lib/mail/domain/solaris-generic.m4 or your site-specific domain m4 file.
# cd /usr/lib/mail/domain # cp solaris-generic.m4 mydomain.m4 |
Use the file name of your choice.
Add the following line to the file that you just created.
define(`confFORWARD_PATH',`')dnl |
If a value for confFORWARD_PATH already exists in the m4 file, replace the value with this null value.
Build and install a new configuration file.
If you need help with this step, refer to How to Build a New sendmail.cf File.
When you edit the .mc file, remember to change DOMAIN(`solaris-generic') to DOMAIN(`mydomain').
If, for example, you want to put all .forward files in a common directory, follow these instructions.
Become root or assume an equivalent role.
For information about roles, refer to “Using Privileged Applications” in System Administration Guide: Security Services.
Make a copy of /usr/lib/mail/domain/solaris-generic.m4 or your site-specific domain m4 file.
# cd /usr/lib/mail/domain # cp solaris-generic.m4 mydomain.m4 |
Use the file name of your choice.
Add the following line to the file that you just created.
define(`confFORWARD_PATH',`$z/.forward:/var/forward/$u')dnl |
If a value for confFORWARD_PATH already exists in the m4 file, replace the value with this new value.
Build and install a new configuration file.
If you need help with this step, refer to How to Build a New sendmail.cf File.
When you edit the .mc file, remember to change DOMAIN(`solaris-generic') to DOMAIN(`mydomain').
This file is not included in the standard release. You must add the file if users are to be allowed to use .forward files to forward mail to a program or to a file. You can create the file manually by using grep to identify all of the shells that are listed in your password file. You can then type the shells into the file. However, the following procedure, which employs a script that can be downloaded, is easier to use.
Download the script.
Become root or assume an equivalent role.
For information about roles, refer to “Using Privileged Applications” in System Administration Guide: Security Services.
To generate a list of shells, run the gen-etc-shells script.
# ./gen-etc-shells.sh > /tmp/shells |
This script uses the getent command to collect the names of shells that are included in the password file sources that are listed in /etc/nsswitch.conf.
Inspect and edit the list of shells in /tmp/shells.
With the editor of your choice, remove any shells that you are not including.
Move the file to /etc/shells.
# mv /tmp/shells /etc/shells |
The following table describes troubleshooting procedures and tips for mail services.
Task |
Description |
For Instructions |
---|---|---|
Testing mail configuration |
Steps for testing changes to the sendmail configuration file | |
Checking mail aliases |
A step to confirm that mail can or cannot be delivered to a specified recipient | |
Testing the rule sets |
Steps for checking the input and returns of the sendmail rule sets | |
Verifying connections to other systems |
Tips for verifying connections to other systems | |
Logging messages by using the syslogd program |
Tips for gathering error message information | |
Checking other sources for diagnostic information |
Tips for getting diagnostic information from other sources |
This section provides some procedures and tips that you can use for troubleshooting problems with mail services.
To test the changes that you make to your configuration file, follow these instructions.
Restart sendmail on any system that has a revised configuration file.
# /etc/init.d/sendmail restart |
Send test messages from each system.
# /usr/lib/sendmail -v names </dev/null |
Specify a recipient's email address.
This command sends a null message to the specified recipient and displays the message activity on your monitor.
Send mail to yourself or other people on the local system by addressing the message to a regular user name.
(Optional) If you are connected to a network, send mail in three directions to someone on another system.
From the main system to a client system
From a client system to the main system
From a client system to another client system
(Optional) If you have a mail gateway, send mail from the mail host to another domain to ensure that the relay mailer and host are configured properly.
(Optional) If you have set up a UUCP connection on your phone line to another host, send mail to someone at that host. Have that person send mail back or call you when the message is received.
Ask someone to send mail to you over the UUCP connection.
The sendmail program cannot detect whether the message is delivered because the program passes the message to UUCP for delivery.
From different systems, send a message to postmaster and ensure that the message is delivered to your postmaster's mailbox.
The following example shows you how to verify an alias.
% mconnect connecting to host localhost (127.0.0.1), port 25 connection open 220 your.domain.com ESMTP Sendmail 8.12.6+Sun/8.12.6; Tue, 12 Nov 2002 13:34:13 -0800 (PST) expn sandy 250 2.1.5 <sandy@phoenix.example.com> quit 221 2.0.0 your.domain.com closing connection % |
In this example, the mconnect program opened a connection to a mail server on a local host and enabled you to test that connection. The program runs interactively, so you can issue various diagnostic commands. For a complete description, see the mconnect(1) man page. The entry, expn sandy, provided the expanded address, sandy@phoenix.example.com. Thus, you have verified that mail can be delivered when using the alias, sandy.
Remember to avoid loops and inconsistent databases when both local and domain-wide aliases are used. Be especially careful to avoid the creation of alias loops when you move a user from one system to another system.
To check the input and returns of the sendmail rule sets, follow these instructions.
Change to address test mode.
# /usr/lib/sendmail -bt |
Test a mail address.
Provide the following numbers and address at the last prompt (>).
> 3,0 mail_address |
Use the mail address that you are testing.
End the session.
Press Control-d.
The following is an example of the output.
% /usr/lib/sendmail -bt ADDRESS TEST MODE (ruleset 3 NOT automatically invoked) Enter <ruleset> <address> > 3,0 sandy@phoenix canonify input: sandy @ phoenix Canonify2 input: sandy < @ phoenix > Canonify2 returns: sandy < @ phoenix . example . com . > canonify returns: sandy < @ phoenix . example . com . > parse input: sandy < @ phoenix . example . com . > Parse0 input: sandy < @ phoenix . example . com . > Parse0 returns: sandy < @ phoenix . example . com . > ParseLocal input: sandy < @ phoenix . example . com . > ParseLocal returns: sandy < @ phoenix . example . com . > Parse1 input: sandy < @ phoenix . example . com . > MailerToTriple input: < mailhost . phoenix . example . com > sandy < @ phoenix . example . com . > MailerToTriple returns: $# relay $@ mailhost . phoenix . example . com $: sandy < @ phoenix . example . com . > Parse1 returns: $# relay $@ mailhost . phoenix . example . com $: sandy < @ phoenix . example . com . > parse returns: $# relay $@ mailhost . phoenix . example . com $: sandy < @ phoenix . example . com . > |
The mconnect program opens a connection to a mail server on a host that you specify and enables you to test that connection. The program runs interactively, so you can issue various diagnostic commands. See the mconnect(1) man page for a complete description. The following example verifies that mail to the user name sandy is deliverable.
% mconnect phoenix connecting to host phoenix (172.31.255.255), port 25 connection open 220 phoenix.example.com ESMTP Sendmail 8.12.0+Sun/8.12.0;Sun, 4 Sep 2001 3:52:56 -0700(PDT) expn sandy 250 2.1.5 <sandy@phoenix.example.com> quit |
If you cannot use mconnect to connect to an SMTP port, check these conditions.
Is the system load too high?
Is the sendmail daemon running?
Does the system have the appropriate /etc/mail/sendmail.cf file?
Is port 25, the port that sendmail uses, active?
Your mail service logs most error messages by using the syslogd program. By default, the syslogd program sends these messages to a system that is called loghost, which is specified in the /etc/hosts file. You can define loghost to hold all logs for an entire NIS domain. If no loghost is specified, error messages from syslogd are not reported.
The /etc/syslog.conf file controls where the syslogd program forwards messages. You can change the default configuration by editing the /etc/syslog.conf file. You must restart the syslog daemon for any changes to become active. To gather information about mail, you can add the following selections to the file.
mail.alert – Messages about conditions that should be fixed now
mail.crit – Critical messages
mail.warning – Warning messages
mail.notice – Messages that are not errors, but might need attention
mail.info – Informational messages
mail.debug – Debugging messages
The following entry in the /etc/syslog.conf file sends a copy of all critical, informational, and debug messages to /var/log/syslog.
mail.crit;mail.info;mail.debug /var/log/syslog |
Each line in the system log contains a timestamp, the name of the system that generated the line, and a message. The syslog file can log a large amount of information.
The log is arranged in a succession of levels. At the lowest level, only unusual occurrences are logged. At the highest level, even the most mundane and uninteresting events are recorded. As a convention, log levels under 10 are considered “useful.” Log levels that are higher than 10 are usually used for debugging. See the “Customizing System Message Logging” in System Administration Guide: Advanced Administration for information about loghost and the syslogd program.
For other diagnostic information, check the following sources.
Look at the Received lines in the header of the message. These lines trace the route that the message took as the message was relayed. Remember to consider time–zone differences.
Look at the messages from MAILER-DAEMON. These messages typically report delivery problems.
Check the system log that records delivery problems for your group of systems. The sendmail program always records its activities in the system log. You might want to modify the crontab file to run a shell script nightly. The script searches the log for SYSERR messages and mails any messages that it finds to the postmaster.
Use the mailstats program to test mail types and determine the number of incoming messages and outgoing messages.
This section describes how you can resolve some sendmail–related error messages that are in the Solaris 9 operating environment. You can also refer to http://www.sendmail.org/faq/.
The following error messages contain two or more of the following types of information.
Cause: What might have happened to cause the message
Description: What the user was doing when the error message occurred
Action: What you can do to fix the problem or to continue with your work
Technical Notes: Background information that might be interesting or helpful to a technical audience, such as developers
See Also: Suggests further reading
451 timeout waiting for input during source
Cause: When sendmail reads from any source that might time out, such as an SMTP connection, the program sets a timer to the value of various Timeout options before reading begins. If the read is not completed before the timer expires, this message appears and reading stops. Usually, this situation occurs during RCPT. The mail message is then queued for later delivery.
Action: If you see this message often, increase the value of various Timeout options in the /etc/mail/sendmail.cf file. If the timer is already set to a large number, look for hardware problems, such as poor network cabling or connections.
See Also: For more information about the Timeout option, refer to Changes to the Timeout Option. If you are using online documentation, the term “timeouts” is a good search string.
550 hostname... Host unknown
Cause: This sendmail message indicates that the destination host machine, which is specified by the portion of the address after the at sign (@), was not found during domain name system (DNS) lookup.
Action: Use the nslookup command to verify that the destination host exists in that domain or other domains, perhaps with a slightly different spelling. Otherwise, contact the intended recipient and ask for a proper address.
550 username... User unknown
Cause: This sendmail message indicates that the intended recipient, who is specified by the portion of the address before the at sign (@), could not be located on the destination host machine.
Action: Check the email address and try again, perhaps with a slightly different spelling. If this remedy does not work, contact the intended recipient and ask for a proper address.
554 hostname... Local configuration error
Cause: This sendmail message usually indicates that the local host is trying to send mail to itself.
Action: Check the value of the $j macro in the /etc/mail/sendmail.cf file to ensure that this value is a fully qualified domain name.
Technical Notes: When the sending system provides its host name to the receiving system in the SMTP HELO command, the receiving system compares its name to the sender's name. If these names are the same, the receiving system issues this error message and closes the connection. The name that is provided in the HELO command is the value of the $j macro.
See Also: For additional information, refer to http://www.sendmail.org/faq/section4.html#4.5.
config error: mail loops back to myself.
Cause: This error message occurs if you set up an MX record and make host bar the mail exchanger for domain foo. However, you fail to configure host bar to know that it is the mail exchanger for domain foo.
Also, another possibility is that both the sending system and the receiving system are identifying as the same domain.
Action: For instructions, refer to http://www.sendmail.org/faq/section4.html#4.5.
host name configuration error
Action: Follow the instructions that were provided for resolving this error message, 554 hostname... Local configuration error.
Technical Notes: This is an old sendmail message, which replaced I refuse to talk to myself and is now replaced by the Local configuration error message.
user unknown
Description: When you try to send mail to a user, the error Username... user unknown is displayed. The user is on the same system.
Action: Check for a typographical error in the entered email address. Otherwise, the user could be aliased to a nonexistent email address in /etc/mail/aliases or in the user's .mailrc file. Also, check for uppercase characters in the user name. Preferably, email addresses should not be case sensitive.
See Also: For additional information, refer to http://www.sendmail.org/faq/section4.html#4.17.
The sendmail program is a mail transport agent. The program uses a configuration file to provide aliasing and forwarding, automatic routing to network gateways, and flexible configuration. The Solaris operating environment supplies standard configuration files that most sites can use. Chapter 21, Mail Services (Overview) provided an introduction to the components of mail services and a description of a typical mail service configuration. Chapter 22, Mail Services (Tasks) explained how to set up and administer an electronic mail system. This chapter provides information on the following topics.
See Chapter 24, What's New With Mail Services (Reference) for a description of the new features that are included in version 8.12 of sendmail. You can also read about changes to mail.local, mailstats, makemap, and about a new maintenance utility, editmap. For details that are not covered in these chapters, see the man pages for sendmail(1M), mail.local(1M), mailstats(1), makemap(1M), and editmap(1M).
This section, which includes the following topics, describes some of the differences in the Solaris version of sendmail as compared to the generic Berkeley version.
The following tables list the flags that are used when compiling the version of sendmail that is delivered with the Solaris 9 release. If your configuration requires other flags, you need to download the source and recompile the binary. You can find information about this process at http://www.sendmail.org.
Table 23–1 General sendmail Flags
Flag |
Description |
---|---|
SOLARIS=20900 |
Support for the Solaris 9 operating environment. |
MILTER |
Support for the Mail Filter API. |
NETINET6 |
Support for IPv6. This flag has been moved from conf.h to Makefile. |
Table 23–2 Maps and Database Types
Flag |
Description |
---|---|
NDBM |
Support for ndbm databases |
NEWDB |
Support for db databases |
USERDB |
Support for the User database |
NIS |
Support for nis databases |
NISPLUS |
Support for nisplus databases |
LDAPMAP |
Support for LDAP maps |
MAP_REGEX |
Support for regular expression maps |
Table 23–3 Solaris Flags
Flag |
Description |
---|---|
SUN_EXTENSIONS |
Support for Sun extensions that are included in sun_compat.o. |
SUN_LOOKUP_MACRO |
Support for the L and G configuration commands in sendmail.cf. Use of these commands is not recommended. |
SUN_INIT_DOMAIN |
For backward compatibility, support for the use of NIS domain names to fully qualify the local host name. For more information, look for vendor-specific information in http://www.sendmail.org. |
SUN_SIMPLIFIED_LDAP |
Support for a simplified LDAP API, which is specific to Sun. For more information, look for vendor-specific information in http://www.sendmail.org. |
VENDOR_DEFAULT=VENDOR_SUN |
Selects Sun as the default vendor. |
The following table lists generic flags that are not used to compile the version of sendmail that is delivered with the Solaris 9 release.
Table 23–4 Generic Flags Not Used in the Solaris Version of sendmail
Flag |
Description |
---|---|
SASL |
Simple Authentication and Security Layer (RFC 2554) |
STARTTLS |
Transaction Level Security (RFC 2487) |
To see a list of the flags that are used to compile sendmail, use the following command.
% /usr/lib/sendmail -bt -d0.10 < /dev/null |
The preceding command does not list the flags that are specific to Sun.
The Solaris release does not include all of the command synonyms that are provided in the generic release from Berkeley. This table includes a complete list of the command aliases. The table also lists whether the commands are included in the Solaris release and how to generate the same behavior by using sendmail.
Table 23–5 Alternate sendmail Commands
Alternate Name |
In the Solaris Release? |
Options With sendmail |
---|---|---|
hoststat | No | sendmail -bh |
mailq | Yes | sendmail -bp |
newaliases | Yes | sendmail -bi |
purgestat | No | sendmail -bH |
smtpd | No | sendmail -bd |
The Solaris 9 version of sendmail includes a configuration option that enables you to define the version of the sendmail.cf file. This option enables older configuration files to be used with the current version of sendmail. You can set the version level to values between 0 and 10. You can also define the vendor. Either Berkeley or Sun is a valid vendor option. If a version level is specified but no vendor is defined, Sun is used as the default vendor setting. The following table lists some of the valid options.
Table 23–6 Version Values for the Configuration File
Field |
Description |
---|---|
V7/Sun |
Setting that was used for version 8.8 of sendmail. |
V8/Sun |
Setting that was used for version 8.9 of sendmail. This setting was included in the Solaris 8 release. |
V9/Sun |
Setting that was used for versions 8.10 and 8.11 of sendmail. |
V10/Sun |
Setting that is used for version 8.12 of sendmail. Version 8.12 is the default for the Solaris 9 release. |
You are urged not to use V1/Sun. For more information, refer to http://www.sendmail.org/vendor/sun/differences.html#4.
For task information, refer to Building the sendmail.cf Configuration File (Task) in Chapter 22, Mail Services (Tasks).
This section describes the software and hardware components of a mail system.
Each mail service includes at least one of each of the following software components.
This section also describes these software components.
The mail user agent is the program that acts as the interface between the user and mail transfer agent. The sendmail program is a mail transfer agent. The Solaris operating environment supplies the following mail user agents.
/usr/bin/mail
/usr/bin/mailx
$OPENWINHOME/bin/mailtool
/usr/dt/bin/dtmail
The mail transfer agent is responsible for the routing of mail messages and the resolution of mail addresses. This agent 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 local delivery agent is a program that implements a mail delivery protocol. The following local delivery agents are provided with the Solaris operating environment.
The UUCP local delivery agent, which uses uux to deliver mail
The local delivery agent, which is mail.local in the standard Solaris release
Chapter 24, What's New With Mail Services (Reference) provides information on these related topics.
Mailer is a sendmail-specific term. A mailer is used by sendmail 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. For task information, refer to Building the sendmail.cf Configuration File (Task) in Chapter 22, Mail Services (Tasks). This section provides a brief description of two types of mailers.
For additional information about mailers, see http://www.sendmail.org/m4/readme.html or /usr/lib/mail/README.
SMTP is the standard mail protocol that is used on the Internet. This protocol defines these mailers.
smtp provides regular SMTP transfers to other servers
esmtp provides extended SMTP transfers to other servers
smtp8 provides SMTP transfers to other servers without converting 8–bit data to MIME
dsmtp provides on-demand delivery by using the F=% mailer flag. Refer to Changes to the MAILER() Declaration and New Delivery Agent Flags in Chapter 24, What's New With Mail Services (Reference).
If possible, avoid using UUCP. For an explanation, refer to http://www.sendmail.org/m4/uucp.html or do a search in /usr/lib/mail/README on this string: USING UUCP MAILERS.
UUCP defines these mailers.
Names in the $=U class are sent to uucp-old. uucp is the obsolete name for this mailer. The uucp-old mailer uses an exclamation-point address in the headers.
Names in the $=Y class are sent to uucp-new. Use this mailer when you know that the receiving UUCP mailer can manage multiple recipients in one transfer. suucp is the obsolete name for this mailer. The uucp-new mailer also uses an exclamation-point address in the headers.
If MAILER(smtp) is also specified in your configuration, two more mailers are defined.
This mailer uses domain-style addresses and, basically, applies the SMTP rewriting rules.
Names in the $=Z class are sent to uucp-uudom. uucp-uudom and uucp-dom use the same header address format, domain-style addresses.
Because the smtp mailer modifies the UUCP mailer, always put MAILER(smtp) before MAILER(uucp) in your .mc file.
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. The login names uniquely identify the users. Complexity is introduced if you are administering a mail system that has more than one system with mailboxes or that has one or more domains. Additional complexity can be generated if you have a UUCP (or other) mail connection to servers outside your network. The information in the following sections can help you understand the parts and complexities of a mail address.
Email addressing uses domains. A domain is a directory structure for network address naming. A domain can have one or more subdomains. The domain and subdomains of an address can be compared to the hierarchy of a file system. Just as a subdirectory is considered to be inside the directory above it, each subdomain in a mail address is considered to be inside the location to its right.
The following table shows some top-level domains.
Table 23–7 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 nonprofit organizations |
Domains are case insensitive. You can use uppercase, lowercase, or mixed-case letters in the domain part of an address without making any difference.
For more information about domains, refer to “Domain Name System (Overview)” in System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP).
When you are working with name service domain names and mail domain names, remember the following.
By default, the sendmail program strips the first component from the NIS or NIS+ domain name to form the mail domain name. For example, if an NIS+ domain name were bldg5.example.com, its mail domain name would be example.com.
Although mail domain addresses are case insensitive, the NIS or NIS+ domain name is not. For the best results, use lowercase characters when setting up the mail and NIS or NIS+ domain names.
The DNS domain name and the mail domain name must be identical.
For more information, refer to Interactions of sendmail With Name Services.
Typically, a mail address has the following format. For further details, refer to Route–Independent Mail Addresses.
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 the following.
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. For information about mailers, refer to Mailers.
The part of the address to the right of the @ sign shows the domain levels, which is where the local address resides. A dot separates each subdomain. The domain part of the address can be an organization, a physical area, or a geographic region. Furthermore, the order of domain information is hierarchical—the more local the subdomain, the closer the subdomain is to the @ sign.
Mail addresses can be route independent. Route-independent addressing requires the sender of an email message to specify the name of the recipient and the final destination. A high-speed network, such as the Internet, uses route-independent addresses. Route-independent addresses can have this format.
user@host.domain |
Route-independent addresses for UUCP connections can have this address format.
host.domain!user |
The increased popularity of the domain-hierarchical naming scheme for computers is making route-independent addresses more common. Actually, 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 first read by searching for the @ sign. The domain hierarchy is then read from the right (the highest level) to the left (the most specific part of the address to the right of the @ sign).
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 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 instance, 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.
The /etc/mail/aliases file and name services such as NIS and NIS+ provide mechanisms for creating aliases for electronic mail addresses. So, 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.
Table 23–8 Conventions for the Format of Mailbox Names
Starting with sendmail version 8, the envelope sender for mail that is sent to a group alias has been changed to the address that is expanded from the owner alias, if an owner alias exists. This change enables any mail errors to be sent to the alias owner, rather than being returned to the sender. With this change, users notice that mail that was sent to an alias looks as if the mail came from the alias owner, when delivered. 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: sandys, ignatz |
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 mail sent to the mygroup alias, the envelope sender changes to mygroup-request.
An alias is an alternate name. For email, you can use aliases to assign a mailbox location or to define mailing lists. For a task map, refer to Administering Mail Alias Files (Task Map) in Chapter 22, Mail Services (Tasks). Also, you can refer to Mail Alias Files in this chapter.
For large sites, the mail alias typically defines the location of a mailbox. Providing a mail alias is like 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 within the building the mail is to be delivered. So, the possibility of an error increases. For example, if two people who are named Kevin Smith are in the same building, only one of them might get mail. To correct the problem, each Kevin Smith should have a room number added to his address.
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 who is named ignatz on system mars, in domain example.com, create the alias ignatz@example instead of ignatz@mars. If user ignatz 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.
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 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 is in the domain planets, could have this entry in the NIS+ aliases table.
fred: fred@planets |
When you create 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 who is named smallberries on system privet, in domain example.com, create the alias as smallberries@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.
The following list describes methods for creating and administering mail alias files.
You can 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 that use 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. Otherwise, you could update all the local /etc/mail/aliases files to keep the aliases synchronized.
Users can also create and use aliases. Users can create aliases either in their local ~/.mailrc file, which only the user can use, or in their local /etc/mail/aliases file, which anyone can use. Users cannot normally create or administer NIS or NIS+ alias files.
You can provide the three required elements of mail configuration in the same system or have separate systems provide these elements.
When users are to communicate with networks outside your domain, you must also add a fourth element, a mail gateway. For more information, refer to Mail Gateway. The following sections describe each hardware component.
A mail host is the machine that you designate as the main mail machine on your network. A mail host is the machine to which other systems at the site forward mail that cannot be delivered. 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. Alternately, you can add the word mailhost similarly to 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. For detailed task information, refer to How to Set Up a Mail Host in Chapter 22, Mail Services (Tasks).
A good candidate for a 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 that is configured as a router from your network to the Internet global network. For more information, refer to Chapter 25, Solaris PPP 4.0 (Overview), Chapter 34, Overview of UUCP, and “Configuring Routers” in System Administration Guide: IP Services. If no systems on your local network have a modem, designate a system as the mail host.
Some sites use standalone machines that are not networked in a time-sharing configuration. Specifically, the standalone machine serves terminals that are attached to its serial ports. You can set up electronic mail for this configuration by designating the standalone system as the mail host of a single-system network. Overview of the Hardware Components in Chapter 21, Mail Services (Overview) provides a figure that shows a typical email configuration.
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, which can be on a local machine or a remote server. A mail server is any system that maintains user mailboxes in its /var/mail directory. For task information, refer to How to Set Up a Mail Server in Chapter 22, Mail Services (Tasks).
The mail server routes all mail from a client. When a client sends mail, the mail server puts the mail 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 systems that are backed up regularly.
If the mail server is not the user's local system, users in configurations that use NFS software can mount the /var/mail directory by using the /etc/vfstab file, if they have root access. Otherwise, users can use the automounter. If NFS support is not available, users can log in to the server to read their mail.
If users on your network send other types of mail, such as audio files or files from desktop publishing systems, you need to allocate more space on the mail server for mailboxes.
By establishing a mail server for all mailboxes, you can simplify your process of doing backups. Backups can be difficult to do when mail is spread over many systems. The disadvantage of storing many mailboxes on one server is that the server can be a single point of failure for many users. However, 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 type of configuration 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. Ensure that the mail client has a mount point to mount the mailbox from the mail server. Also, ensure that the alias for the client is directed to the mail server's host name, not to the client's name. For task information, refer to How to Set Up a Mail Client in Chapter 22, Mail Services (Tasks).
The mail gateway is a machine that handles connections between networks that run different communications protocols or communications between different networks that use the same protocol. For example, a mail gateway might connect a TCP/IP network to a network that runs the Systems Network Architecture (SNA) protocol suite.
The simplest mail gateway to set up is the mail gateway 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 the gateway to send and receive mail outside your domain.
You can set up a mail gateway between two networks that use unmatched mailers, as shown in the next figure. To support this configuration, 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 conform to your situation.
If you have a machine that provides 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 other networks, and set up that gateway as the mail gateway. For task information, refer to How to Set Up a Mail Gateway in Chapter 22, Mail Services (Tasks).
Mail services include many programs and daemons that interact with each other. This section introduces the files, programs, terms, and concepts that are related to administering electronic mail.
The following table shows the contents of the /usr/bin directory, which is 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 |
A link to /usr/lib/sendmail. Used to list the mail queue. |
|
File |
A program that is used to read mail statistics that are stored in the /etc/mail/statistics file (if present). |
|
File |
A user agent. |
|
File |
A program that connects to the mailer for address verification and debugging. |
|
File |
A command to “uncompile” the alias database. Refer to the uncompile information that is provided in the man page for praliases(1). |
|
Link |
A link to /usr/bin/mail. Command that is often used to permit only the sending of mail. |
|
File |
A command to set up an automatic reply to mail. |
The following table shows the contents of the /etc/mail directory.
Name |
Type |
Description |
---|---|---|
File |
Default settings for the mailtool user agent. |
|
File |
Mail-forwarding information. |
|
File |
Default binary form of mail-forwarding information that is created by running newaliases. |
|
File |
Binary form of mail-forwarding information that is created by running newaliases. Can still be used, but is no longer used by default in the Solaris 9 release. |
|
File |
Binary form of mail-forwarding information that is created by running newaliases. Can still be used, but is no longer used by default in the Solaris 9 release. |
|
File |
Default settings for the mailx user agent. |
|
File |
Sample configuration file for main systems. |
|
File |
List of all domains for which relaying is allowed. By default, only the local domain is allowed. |
|
File |
Configuration file for mail routing. |
|
File |
New configuration file for the mail submission program (MSP). For more information, refer to New Configuration File, submit.cf. |
|
File |
Optional file that you can create if the number of aliases for the mail host is too long. |
|
File |
Help file that is used by the SMTP HELP command. |
|
File |
File that lists the PID of the listening daemon and is now in /var/run. |
|
File |
sendmail statistics file. If this file is present, sendmail logs the amount of traffic through each mailer. Previously, this file was called sendmail.st. |
|
File |
Sample configuration file for subsidiary systems. |
|
File |
File that lists the users (one user per line) who can be trusted to perform certain mail operations. By default, only root is in this file. Certain mail operations, when performed by untrusted users, result in the following warning, X-Authentication-Warning: header being added to a message. |
Table 23–9 shows the contents of the /usr/lib directory, which is used for mail services.
Table 23–9 Contents of the /usr/lib Directory
Name |
Type |
Description |
---|---|---|
File |
Mailer that delivers mail to mailboxes. |
|
File |
Routing program, also known as the mail transfer agent. |
|
File |
Shell program (sendmail restricted shell) that uses the “|program” syntax of sendmail to restrict programs that sendmail can run to those programs listed in the /var/adm/sm.bin directory. Refer to the smrsh(1M) man page for recommendations on what to include in /var/adm/sm.bin. To enable, include this m4 command, FEATURE(`smrsh'), in your mc file. |
Within the /usr/lib directory is a subdirectory, mail, that contains all of the necessary files to build a sendmail.cf file. The contents of mail are shown in Table 23–10.
Table 23–10 Contents of the /usr/lib/mail Directory Used for Mail Services
Name |
Type |
Description |
---|---|---|
File |
Describes the configuration files. |
|
Directory |
Provides site-dependent and site-independent descriptions of hosts. |
|
File |
Previously named cf/main-v7sun.mc. Is the main configuration file. |
|
File |
Provides rules for building new configuration files. |
|
File |
Is the configuration file for the mail submission program (MSP), which is used to submit messages. |
|
File |
Previously named cf/subsidiary-v7sun.mc. Is the configuration file for hosts that NFS-mount /var/mail from another host. |
|
Directory |
Provides site-dependent subdomain descriptions. |
|
File |
Is the generic domain file from Berkeley. |
|
File |
Is the domain file with changes that make sendmail function like previous Solaris versions. However, relaying is disabled completely, sender addresses with no host name are rejected, and unresolvable domains are rejected. |
|
File |
Is the default domain file with changes that make sendmail function like previous Solaris versions. |
|
Directory |
Contains definitions of specific features for particular hosts. See README for a full description of the features. |
|
Directory |
Contains site-independent include files. |
|
Directory |
Contains definitions of mailers, which include local, smtp, and uucp. |
|
Directory |
Describes various operating system environments. |
|
File |
Defines default local mailer as mail.local. |
|
File |
Defines default local mailer as mail.local. |
|
File |
Defines local mailer as mail. |
|
File |
Defines local mailer as mail.local (in LMTP mode), enables IPv6, specifies /var/run as the directory for the sendmail.pid file. |
|
Directory |
Contains shell scripts that are 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 for mail services, as shown in Table 23–11.
Table 23–11 Other Files Used for Mail Services
Mail services are provided by a combination of the following programs, which interact as shown in the simplified illustration in Figure 23–2.
For a more detailed illustration, refer to the figure in sendmail Features.
The following is a description of the interactions of mail programs.
Users send messages by using programs such as mailx or mailtool. See the man pages for mailx(1) or mailtool(1) for information about these programs.
The message is collected by the program that generated the message, and the message is passed to the sendmail daemon.
The sendmail daemon parses the addresses (divides them into identifiable segments) in the message. The daemon uses information from the configuration file, /etc/mail/sendmail.cf, to determine network name syntax, aliases, forwarding information, and network topology. By using this information, sendmail determines which route a message must follow 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 the mail by using mail, mailx, mailtool, or a similar 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.
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).
Figure 23–3 shows how sendmail uses aliases. Programs that read mail, such as /usr/bin/mailx, can have aliases of their own, which are expanded before the message reaches sendmail. The aliases for sendmail can originate from a number of name service sources, such as local files, NIS, or NIS+. The order of the lookup is determined by the nsswitch.conf file. Refer to the nsswitch.conf(4) man page.
The sendmail program provides the following features.
sendmail is reliable. The program is designed to correctly deliver every message. No message should ever become completely lost.
sendmail uses existing software for delivery whenever possible.
sendmail can be configured to handle complex environments, including multiple connections to a single network type, such as UUCP or Ethernet. sendmail checks the contents of an address as well as its syntax to determine which mailer to use.
sendmail uses configuration files to control mail configuration instead of requiring that configuration information be compiled into the code.
Users can maintain their own mailing lists. Additionally, individuals can specify their own forwarding mechanism without modifying the domain-wide alias file, typically located in the domain-wide aliases that are maintained by NIS or NIS+.
Each user can specify a custom mailer to process incoming mail. The custom mailer can provide functions such as returning a message that reads: “I am on vacation.” See the vacation(1) man page for more information.
sendmail batches addresses to a single host to reduce network traffic.
Figure 23–4 shows how sendmail interacts with the other programs in the mail system.
As shown in Figure 23–4, the user interacts with a mail-generating and mail-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, you can use sendmail as an Internet mail gateway. See Interactions of Mail Programs for a more detailed description of the process.
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 that is 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 three default configuration files in the /etc/mail directory.
A configuration file that is named main.cf for the system, or systems, you designate as the mail host or a mail gateway.
A configuration file that is named subsidiary.cf, which is a duplicate copy of the default sendmail.cf file.
A configuration file that is named submit.cf, which is used to run sendmail in mail-submission program mode, instead of daemon mode. For more information, refer to New Configuration File, submit.cf.
The configuration file that you use on a system depends on the role of the system 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 mail gateway, copy the main.cf file and rename the file to sendmail.cf in the /etc/mail directory. Then reconfigure the sendmail configuration file to set the relay mailer and relay host parameters that are needed for your mail configuration. For task information, refer to Setting Up Mail Services (Task Map) or Building the sendmail.cf Configuration File (Task) in Chapter 22, Mail Services (Tasks).
The following list describes some configuration parameters that you can change, depending on the requirements of your site.
Time values, which specify the following information.
Read timeouts. Refer to Changes to the Timeout Option.
Length of time a message remains undelivered in the queue before the message is returned to the sender. Refer to New Queue Features. For a task map, refer to Administering the Queue Directories (Task Map).
Delivery modes, which specify how quickly mail is delivered.
Load limits, which increase efficiency during busy periods by not attempting to deliver large messages, messages to many recipients, and messages to sites that have been down for a long time.
Log level, which specifies the kinds of problems that are logged.
You can use any of the following files, maps, or tables to maintain aliases.
Your method of maintaining aliases depends on who uses the alias and who needs to be able to change the alias. Each type of alias has unique format requirements.
If you are looking for task information, refer to Administering Mail Alias Files (Task Map) in Chapter 22, Mail Services (Tasks).
Aliases that are listed in a .mailrc file are accessible only by the user who owns the file. This restriction enables users to establish an alias file that they control and that is usable only by its owner. Aliases in a .mailrc file adhere to the following format.
alias aliasname value value value ... |
aliasname is the name that the user uses when sending mail, and value is a valid email address.
If a user establishes a personal alias for scott that does not match the email address for scott in the name service, mail is routed to the wrong person when people try to reply to mail that is generated by this user. The only workaround is to use any of the other aliasing mechanisms.
Any alias that is established in the /etc/mail/aliases file can be used by any user who knows the name of the alias and the host name of the system that contains the file. Distribution list formats in a local /etc/mail/aliases file adhere to the following format.
aliasname: value,value,value ... |
aliasname is the name that the user uses when sending mail to this alias, and value is a valid email address.
If your network is not running a name service, the /etc/mail/aliases file of each system should contain entries for all mail clients. You can either edit the file on each system or edit the file on one system and copy the file to each of the other systems.
The aliases in the /etc/mail/aliases file are stored in text form. When you edit the /etc/mail/aliases file, you need to run the newaliases program. This program recompiles the database and makes the aliases available in binary form to the sendmail program. For task information, refer to How to Set Up a Local Mail Alias File in Chapter 22, Mail Services (Tasks). Otherwise, you can use the AdminTool's Database Manager to administer the mail aliases that are stored in the local /etc files.
You can create aliases for only local names—a current host name or no host name. For example, an alias entry for user ignatz who has a mailbox on the system saturn would have the following entry in the /etc/mail/aliases file.
ignatz: ignatz@saturn |
You should create an administrative account for each mail server. You create such an account by assigning a mailbox on the mail server to root and by adding an entry for root to the /etc/mail/aliases file. For example, if the system saturn is a mailbox server, add the entry root: sysadmin@saturn to the /etc/mail/aliases file.
Normally, only the root user can edit this file. However, when you use the AdminTool, all users in group 14, which is the sysadmin group, can change the local file. Another option is to create the following entry.
aliasname: :include:/path/aliasfile |
aliasname is the name that the user uses when sending mail, and /path/aliasfile is the full path to the file that contains the alias list. The alias file should include email entries, one entry on each line, and no other notations.
user1@host1 user2@host2 |
You can define additional mail files in /etc/mail/aliases to keep a log or a backup copy. The following entry stores all mail that is sent to aliasname in filename.
aliasname: /home/backup/filename |
You can also route the mail to another process. The following example stores a copy of the mail message in filename and prints a copy.
aliasname: "|tee -a /home/backup/filename |lp" |
For a task map, refer to Administering Mail Alias Files (Task Map) in Chapter 22, Mail Services (Tasks).
All users in a local domain can use the entries that are in the NIS aliases map. The reason is that the sendmail program can use the NIS aliases map instead of the local /etc/mail/aliases files to determine mailing addresses. For more information, refer to the nsswitch.conf(4) man page.
Aliases in the NIS aliases map adhere to the following format.
aliasname: value,value,value ... |
aliasname is the name that the user uses when sending mail, and value is a valid email address.
The NIS aliases map should contain entries for all mail clients. In general, only the root user on the NIS master can change these entries. This type of alias might not be a good choice for aliases that are constantly changing. However, such aliases can be useful if the aliases point to another alias file, as in the following syntax example.
aliasname: aliasname@host |
aliasname is the name that the user uses when sending mail, and host is the host name for the server that contains an /etc/mail/alias file.
For task information, refer to How to Set Up an NIS mail.aliases Map in Chapter 22, Mail Services (Tasks).
The NIS+ mail_aliases table contains the names by which a system or person is known in the local domain. The sendmail program can use the NIS+ mail_aliases table, instead of the local /etc/mail/aliases files, to determine mailing addresses. Refer to the aliasadm(1M) and nsswitch.conf(4) man pages for more information.
Aliases in the NIS+ mail_aliases table adhere to the following format:
alias: expansion # ["options " # "comments"] |
Table 23–12 describes the four columns that are in an NIS+ mail_aliases table.
Table 23–12 Columns in the NIS+ mail_aliases Table
Column |
Description |
---|---|
alias |
The name of the alias |
expansion |
The value of the alias or a list of aliases as it would appear in a sendmail /etc/mail/aliases file |
options |
The column that is reserved for future use |
comments |
The column for comments about an individual alias |
The NIS+ mail_aliases table should contain entries for all mail clients. You can list, create, modify, and delete entries in the NIS+ aliases table with the aliasadm command. To use the aliasadm command, you must be a member of the NIS+ group that owns the aliases table. For task information, refer to How to Manage Alias Entries in an NIS+ mail_aliases Table in Chapter 22, Mail Services (Tasks). Alternately, you can use the AdminTool's Database Manager to administer the NIS+ mail aliases.
If you are creating a new NIS+ aliases table, you must initialize the table before you create the entries. If the table exists, no initialization is needed.
Users can create a .forward file in their home directories that sendmail, along with other programs, can use to redirect mail or send mail. Refer to the following topics.
For a task map, refer to Administering .forward Files (Task Map) in Chapter 22, Mail Services (Tasks).
The following list describes some situations that you can avoid or easily fix.
If mail is not being delivered to the expected address, check the user's .forward file. The user might have put the .forward file in the home directory of host1, which forwards mail to user@host2. When the mail arrives at host2, sendmail checks for user in the NIS or NIS+ aliases and sends the message back to user@host1, which results in a loop and more bounced mail.
To avoid security problems, never put .forward files in the root and bin accounts. If necessary, forward the mail by using the aliases file instead.
For the .forward files to be an effective part of mail delivery, ensure that the following controls (mostly permissions settings) are correctly applied.
The .forward file must be writable only by the owner of the file. This restriction prevents other users from breaking security.
The paths that lead to the home directory must be owned and writable by root only. For example, if a .forward file is in /export/home/terry, /export and /export/home must be owned and writable by root only.
The actual home directory should be writable only by the user.
The .forward file cannot be a symbolic link, and this file cannot have more than one hard link.
You can create a .forward.hostname file to redirect mail that is sent to a specific host. For example, if a user's alias has changed from sandy@phoenix.example.com to sandy@example.com, place a .forward.phoenix file in the home directory for sandy.
% cat .forward.phoenix sandy@example.com "|/usr/bin/vacation sandy" % cat .vacation.msg From: sandy@example.com (via the vacation program) Subject: my alias has changed My alias has changed to sandy@example.com. Please use this alias in the future. The mail that I just received from you has been forwarded to my new address. Sandy |
In this example, mail can be forwarded to the correct place while the sender is notified of the alias change. Because the vacation program permits only one message file, you can forward only one message at a time. However, if the message is not host specific, one vacation message file can be used by .forward files for many hosts.
Another extension to the forwarding mechanism is the .forward+detail file. The detail string can be any sequence of characters except operator characters. The operator characters are .:%&!^[]+. By using this type of file, you can determine if someone else is using your email address without your knowledge. For instance, if a user tells someone to use the email address sandy+test1@example.com, the user would be able to identify any future mail that was delivered to this alias. By default, any mail that is sent to the sandy+test1@example.com alias is checked against the alias and the .forward+detail files. If no matches are made, the mail falls back to delivery to sandy@example.com, but the user is able to see a change in the To: mail header.
This file is used to store startup options for sendmail so that the options are not removed when a host is upgraded. The following variables can be used.
Selects additional options to be used with the client daemon, which looks in the client-only queue (/var/spool/clientmqueue) and acts as a client queue runner. No syntax checking is done, so be careful when making changes to this variable.
Similar to the QUEUEINTERVAL option, CLIENTQUEUEINTERVAL sets the time interval for mail queue runs. However, the CLIENTQUEUEINTERVAL option controls the functions of the client daemon, instead of the functions of the master daemon. Typically, the master daemon is able to deliver all messages to the SMTP port. However, if the message load is too high or the master daemon is not running, then messages go into the client-only queue, /var/spool/clientmqueue. The client daemon, which checks in the client-only queue, then acts as a client queue processor.
Enables an SMTP client and server to interact immediately without waiting for the queue run intervals, which are periodic. The server can immediately deliver the portion of its queue that goes to the specified hosts. For more information, refer to the etrn(1M) man page.
Selects the mode to start sendmail with. Use the -bd option or leave it undefined.
Selects additional options to be used with the master daemon. No syntax checking is done, so be careful when making changes to this variable.
Sets the interval for mail queue runs on the master daemon. # can be a positive integer that is followed by either s for seconds, m for minutes, h for hours, d for days, or w for weeks. The syntax is checked before sendmail is started. If the interval is negative or if the entry does not end with an appropriate letter, the interval is ignored and sendmail starts with a queue interval of 15 minutes.
Enables one persistent queue runner that sleeps between queue run intervals, instead of a new queue runner for each queue run interval. You can set this option to p, which is the only setting available. Otherwise, this option is not set.
The path that a mail message follows during delivery depends on the setup of the client system and the topology of the mail domain. Each additional level of mail hosts or mail domains can add another alias resolution, but the routing process is basically the same on most hosts.
You can set up a client system to receive mail locally. Receiving mail locally is known as running sendmail in local mode. Local mode is the default for all mail servers and some clients. On a mail server or a mail client in local mode, a mail message is routed the following way.
The following example assumes that you are using the default rule set in the sendmail.cf file.
Expand the mail alias, if possible, and restart the local routing process.
The mail address is expanded by checking for the mail alias in the name service and substituting the new value, if a new value is found. This new alias is then checked again.
If the mail is local, deliver the mail to /usr/lib/mail.local.
The mail is delivered to a local mailbox.
If the mail address includes a host in this mail domain, deliver the mail to that host.
If the address does not include a host in this domain, forward the mail to the mail host.
The mail host uses the same routing process as the mail server. However, the mail host can receive mail that is addressed to the domain name as well as to the host name.
This section describes domain names as they apply to sendmail and name services. Furthermore, this section describes the rules for effective use of name services, and the specific interactions of sendmail with name services. For details, refer to the following topics.
If you are looking for related task information, refer to How to Use DNS With sendmail or Administering Mail Alias Files (Task Map) in Chapter 22, Mail Services (Tasks).
The standard sendmail.cf file uses mail domains to determine whether mail is delivered directly or through a mail host. Intradomain mail is delivered through a direct SMTP connection, while interdomain mail is forwarded to a mail host.
In a secure network, only a few selected hosts are authorized to generate packets that are targeted to external destinations. Even if a host has the IP address of the remote host that is external to the mail domain, the establishment of an SMTP connection is not guaranteed. The standard sendmail.cf assumes the following.
The current host is not authorized to send packets directly to a host outside the mail domain.
The mail host is capable of forwarding the mail to an authorized host that can transmit packets directly to an external host. Actually, the mail host can be an authorized host.
With these assumptions, the mail host is responsible for delivering or forwarding interdomain mail.
sendmail imposes various requirements on name services. To improve your understanding of these requirements, this section first describes the relationship of mail domains to name service domains. Then the section describes the various requirements. Refer to the following.
Man pages for in.named(1M), nis+(1), nisaddent(1M), and nsswitch.conf(4)
The mail domain name must be a suffix of the name service domain. For example, if the domain name of the name service is A.B.C.D, the mail domain name could be one of the following.
A.B.C.D
B.C.D
C.D
D
When first established, the mail domain name is often identical to the name service domain. As the network grows, the name service domain can be divided into smaller pieces to make the name service more manageable. However, the mail domain often remains undivided to provide consistent aliasing.
This section describes the requirements that sendmail imposes on name services.
A host table or map in a name service must be set up to support three types of gethostbyname() queries.
mailhost – Some name service configurations satisfy this requirement automatically.
Full host name (for example, smith.admin.acme.com) – Many name service configurations satisfy this requirement.
Short host name (for example, smith) – sendmail must connect to the mail host in order to forward external mail. To determine if a mail address is within the current mail domain, gethostbyname() is invoked with the full host name. If the entry is found, the address is considered internal.
NIS, NIS+, and DNS support gethostbyname() with a short host name as an argument, so this requirement is automatically satisfied.
Two additional rules about the host-name service need to be followed to establish efficient sendmail services within a name service.
gethostbyname() with full host-name argument and short host-name argument should yield consistent results. For example, gethostbyname(smith.admin.acme.com) should return the same result as gethostbyname(smith), if both functions are called from the mail domain admin.acme.com.
For all name service domains under a common mail domain, gethostbyname() with a short host name should yield the same result. For example, if the mail domain smith.admin.acme.com is given, gethostbyname(smith) should return the same result when the call originates from either the ebb.admin.acme.com domain or the esg.admin.acme.com domain. The mail domain name is usually shorter than the name service domain, which gives this requirement special implications for various name services.
For more information about the gethostbyname() function, refer to the gethostbyname(3NSL) man page.
The following list describes the interactions of sendmail and NIS and provides some guidance.
Mail domain name – If you are setting up NIS as the primary name service, sendmail automatically strips the first component of the NIS domain name and uses the result as the mail domain name. For example, ebs.admin.acme.com becomes admin.acme.com.
Mail host name – You must have a mailhost entry in the NIS host map.
Full host names – The normal NIS setup does not “understand” the full host name. Rather than trying to make NIS understand the full host name, turn off this requirement from the sendmail side by editing the sendmail.cf file and replacing all occurrences of %l with %y. This change turns off sendmail's interdomain mail detection. If the target host can be resolved to an IP address, a direct SMTP delivery is attempted. Ensure that your NIS host map does not contain any host entry that is external to the current mail domain. Otherwise, you need to further customize the sendmail.cf file.
Matching full host names and short host names – Follow the previous instructions on how to turn off gethostbyname() for a full host name.
Multiple NIS domains in one mail domain – All NIS host maps under a common mail domain should have the same set of host entries. For example, the host map in the ebs.admin.acme.com domain should be the same as the host map in the esg.admin.acme.com. Otherwise, one address might work in one NIS domain, but fail in the other NIS domain.
For task information, refer to Administering Mail Alias Files (Task Map) in Chapter 22, Mail Services (Tasks).
The following list describes the interactions of sendmail with NIS and DNS and provides some guidance.
Mail domain name – If you are setting up NIS as the primary name service, sendmail automatically strips the first component of the NIS domain name and uses the result as the mail domain name. For example, ebs.admin.acme.com becomes admin.acme.com.
Mail host name – When the DNS forwarding feature is turned on, queries that NIS cannot resolve are forwarded to DNS, so you do not need a mailhost entry in the NIS host map.
Full host names – Although NIS does not “understand” full host names, DNS does understand. This requirement is satisfied when you follow the regular procedure for setting up NIS and DNS.
Matching full host names and short host names – For every host entry in the NIS host table, you must have a corresponding host entry in DNS.
Multiple NIS domains in one mail domain – All NIS host maps under a common mail domain should have the same set of host entries. For example, the host map in the ebs.admin.acme.com domain should be the same as the host map in the esg.admin.acme.com domain. Otherwise, one address might work in one NIS domain, but fail in the other NIS domain.
For task information, refer to How to Use DNS With sendmail and Administering Mail Alias Files (Task Map) in Chapter 22, Mail Services (Tasks).
The following list describes the interactions of sendmail with NIS+ and provides some guidance.
Mail domain name - If you are setting up NIS+ as your primary name service, sendmail can check the mail domain from the NIS+ sendmailvars table. This NIS+ table has one key column and one value column. To set up your mail domain, you must add one entry to this table. This entry should have the key column set to the literal string maildomain and the value column set to your mail domain name. An example is admin.acme.com. Although NIS+ allows any string in the sendmailvars table, the suffix rule still applies for the mail system to work correctly. You can use nistbladm to add the maildomain entry to the sendmailvars table. Notice in the following example that the mail domain is a suffix of the NIS+ domain.
nistbladm -A key="maildomain" value=<mail domain> sendmailvars.org_dir.<NIS+ domain> |
Mailhost host name - You must have a mailhost entry in the NIS+ hosts table.
Full host names – NIS+ “understands” the full host name. Following the regular NIS+ setup procedure satisfies this requirement.
Matching full host names and short host names – To satisfy this requirement, you can duplicate the entries in the host table. Otherwise, you can enter all host entries in the user name service domains into a master host table at mail domain level.
Multiple NIS domains in one mail domain – To satisfy this requirement, you can duplicate the entries in all the host tables. Otherwise, you can type all host entries in the user name service domains into a master host table at mail domain level. Effectively, you are merging multiple host tables that are logical or physcial into one host table. Therefore, the same host name cannot be reused in the multiple name service domain that shares a common mail domain.
For task information, refer to Administering Mail Alias Files (Task Map) in Chapter 22, Mail Services (Tasks).
The following list describes the interactions of sendmail with NIS+ and DNS and provides some guidance.
Mail domain name – If you are setting up NIS+ as your primary name service, sendmail can check the mail domain from the NIS+ sendmailvars table. This NIS+ table has one key column and one value column. To set up your mail domain, you must add one entry to this table. This entry should have the key column set to the literal string maildomain and the value column set to your mail domain name. An example is admin.acme.com. Although NIS+ allows any string in the sendmailvars table, the suffix rule still applies for the mail system to work correctly. You can use nistbladm to add the maildomain entry to the sendmailvars table. Notice in the following example that the mail domain is a suffix of the NIS+ domain.
nistbladm -A key="maildomain" value=<mail domain> sendmailvars.org_dir.<NIS+ domain> |
Mailhost host name – If your network uses both NIS+ and DNS as the source for the host database, you can put the mailhost entry in either the NIS+ or DNS host table. Ensure that your users include both NIS+ and DNS as the source for the host database in the /etc/nsswitch.conf file.
Full host names – Both NIS+ and DNS “understand” full host names. Following the regular NIS+ and DNS setup procedures satisfies this requirement.
Matching full host names and short host names – For every host entry in the NIS+ host table, you must have a corresponding host entry in DNS.
Multiple NIS domains in one mail domain – To satisfy this requirement, you can duplicate the entries in all the host tables Alternately, you can type all host entries in the user name service domains into a master host table at the mail domain level.
For task information, refer to Administering Mail Alias Files (Task Map) and How to Use DNS With sendmail in Chapter 22, Mail Services (Tasks).
Chapter 21, Mail Services (Overview) provides an introduction to the components of mail services and a description of a typical mail configuration. Chapter 22, Mail Services (Tasks) explains how to set up and administer an electronic mail system with standard configuration files. Chapter 23, Mail Services (Reference) describes in greater detail the components of mail services. Chapter 23, Mail Services (Reference) also describes the mail service programs and files, the mail routing process, and the interactions of sendmail with name services. This chapter describes the new features that are included in version 8.12 of sendmail, the version that is in this Solaris 9 release. You can also read about changes to mail.local, mailstats, and makemap. This chapter also describes a new maintenance utility, editmap. The following list can help you in your search on a specific topic.
This section contains information on the following topics.
Version 8.12 of sendmail includes an additional configuration file, /etc/mail/submit.cf. This new file, submit.cf, is used to run sendmail in mail-submission program mode instead of daemon mode. Mail-submission program mode, unlike daemon mode, does not require root privilege, so this new paradigm provides better security.
See the following list of functions for submit.cf:
sendmail uses submit.cf to run in mail submission program (MSP) mode, which submits email messages and can be invoked by programs (such as mailx), as well as by users. Refer to the description of the -Ac option and the -Am option in New or Deprecated Command-Line Options.
submit.cf is used in the following operating modes:
-bm, which is the default operating mode
-bs, which uses standard input to run SMTP
-bt, which is the test mode that is used to resolve addresses
sendmail, when using submit.cf, does not run as an SMTP daemon.
sendmail, when using submit.cf, uses /var/spool/clientmqueue, the client-only mail queue, which holds messages that were not delivered to the sendmail daemon. Messages in the client-only queue are delivered by the client “daemon,” which is really acting as a client queue runner.
By default, sendmail uses submit.cf periodically to run the MSP queue (otherwise known as the client-only queue), /var/spool/clientmqueue.
/usr/lib/sendmail -Ac -q15m |
Note the following:
submit.cf is provided automatically when you install or upgrade to the Solaris 9 operating environment.
submit.cf requires no planning or preliminary procedures prior to the installation of the Solaris 9 operating environment.
Unless you specify a configuration file, sendmail automatically uses submit.cf as required. Basically, sendmail knows which tasks are appropriate for submit.cf and which tasks are appropriate for sendmail.cf.
submit.cf is not to be modified.
The sendmail.cf configuration file is for the daemon mode. When using this file, sendmail is acting as a mail transfer agent (MTA), which is started by root.
/usr/lib/sendmail -L sm-mta -bd -q1h |
See the following list of other distinguishing functions for sendmail.cf:
By default, sendmail.cf accepts SMTP connections on ports 25 and 587.
By default, sendmail.cf runs the main queue, /var/spool/mqueue.
With the addition of submit.cf, the following functional changes have occurred:
In version 8.12 of sendmail, only root can run the mail queue. For further details, refer to the changes that are described in the mailq(1) man page. For new task information, refer to Administering the Queue Directories (Task Map).
The mail-submission program mode runs without root privilege, which might prevent sendmail from having access to certain files (such as the .forward files). Therefore, the -bv option for sendmail could give the user misleading output. No workaround is available.
Prior to sendmail version 8.12, if you were not running the sendmail daemon (that is, running in daemon mode), you would only prevent the delivery of inbound mail. Now, in sendmail version 8.12, if you are not running the sendmail daemon with the default configuration, you also prevent the delivery of outbound mail. The client queue runner (also known as the mail submission program) must be able to submit mail to the daemon on the local SMTP port. If the client queue runner tries to open an SMTP session with the local host and the daemon is not listening on the SMTP port, the mail remains in the queue. The default configuration does run a daemon, so this problem does not occur if you are using the default configuration. However, if you have disabled your daemon, refer to Managing Mail Delivery by Using an Alternate Configuration (Task) for a way to resolve this problem.
The following table describes new command-line options for sendmail. Other command-line options are described in the sendmail(1M) man page.
Table 24–1 New Command-Line Options for sendmail
Option |
Description |
---|---|
Indicates that you want to use the configuration file, submit.cf, even if the operation mode does not indicate an initial mail submission. For more information about submit.cf, refer to New Configuration File, submit.cf. |
|
Indicates that you want to use the configuration file, sendmail.cf, even if the operation mode indicates an initial mail submission. For more information, refer to New Configuration File, submit.cf. |
|
Indicates that you are printing the number of entries in each queue. |
|
Indicates that the message that is being submitted from the command line is for relaying, not for initial submission. The message is rejected if the addresses are not fully qualified. No canonicalization is done. As is noted in the Release Notes that are part of the sendmail distribution on ftp://ftp.sendmail.org, improperly formed messages might be rejected in future releases. |
|
Sets the identifier that is used for syslog messages to the supplied tag. |
|
Processes only jobs that contain this substring of one of the recipients. When ! is added, the option processes only jobs that do not have this substring of one of the recipients. |
|
Processes only jobs that contain this substring of the queue ID. When ! is added, the option processes only jobs that do not have this substring of the queue ID. |
|
Processes only jobs that contain this substring of the sender. When ! is added, the option processes only jobs that do not have this substring of the sender. |
|
Processes saved messages in the queue once, without using the fork system call, and runs the process in the foreground. Refer to the fork(2) man page. |
|
Processes only the messages in the name queue group. |
|
Processes saved messages in the queue at a specific interval of time with a single child that is forked for each queue. The child sleeps between queue runs. This new option is similar to the -qtime, which periodically forks a child to process the queue. |
|
As is noted in the Release Notes that are part of the sendmail distribution on ftp://ftp.sendmail.org, this option is not available in version 8.12. Mail user agents should use the -G argument. |
This section contains a table of new and revised configuration file options and information on the following related topics.
Deprecated and Unsupported Configuration File Options for sendmail
Additional Arguments for the PidFile and ProcessTitlePrefix Options
When you declare these options, use one of the following syntaxes.
O OptionName=argument # for the configuration file -OOptionName=argument # for the command line define(`m4Name',argument) # for m4 configuration |
If you need to build a new sendmail.cf file, refer to Building the sendmail.cf Configuration File (Task) in Chapter 22, Mail Services (Tasks).
The following table describes new and revised options for sendmail.
Table 24–2 New and Revised Options for sendmail
Option |
Description |
---|---|
m4 name: confBAD_RCPT_THROTTLE Argument: number The new option limits the rate at which recipients in the SMTP envelope are accepted after a threshold number of recipients has been rejected. |
|
For details, see New ClientPortOptions Option. |
|
m4 name: confCONNECTION_RATE_THROTTLE Argument: number The option ConnectionRateThrottle now limits the number of connections per second to each daemon, not the total number of connections. |
|
m4 name: confCONTROL_SOCKET_NAME Argument: filename. The recommended socket name is /var/spool/mqueue/.smcontrol. For security, this UNIX domain socket must be in a directory that is accessible only by root. When this new option is set, the option creates a control socket for daemon management. This option enables an external program to control and query the status of the running sendmail daemon by way of a named socket. The socket is similar to the ctlinnd interface to the INN news server. If this option is not set, no control socket is available. |
|
For details, see Changes to DaemonPortOptions Option. |
|
m4 name: confDF_BUFFER_SIZE Argument: number The new option controls the maximum size (in bytes) of a memory-buffered data (df) file before a disk-based file is used. The default is 4096 bytes. You should not have to change the default for the Solaris operating environment. |
|
m4 name: confDEAD_LETTER_DROP Argument: filename The new option, which you should not need to set, defines the location of the system-wide dead.letter file, which was formerly hard-coded to /usr/tmp/dead.letter. |
|
m4 name: confDELAY_LA Argument: number If this new option is set to a value that is greater than zero, the option does the following: Delays connections by one second when the load averages exceed a specified value Delays the execution of most SMTP commands by one second Otherwise, if the option is not set, the default value, which is zero, does not change the behavior of sendmail. |
|
m4 name: confDELIVER_BY_MIN Argument: time The new option enables a client to specify a minimum amount of time for an email message to be delivered, as specified in RFC 2852, Deliver By SMTP Service Extension. If the time is set to zero, no time is listed. If the time is set to less than zero, the extension is not offered. If the time is set to greater than zero, the extension is listed as the minimum time for the EHLO keyword, DELIVERBY. |
|
m4 name: confDIRECT_SUBMISSION_MODIFIERS Argument: modifiers The new option defines ${daemon_flags} for direct (command-line) submissions. If this option is not set, the value of ${daemon_flags} is either CC f, if the option -G is used, or c u. |
|
You can use the following new arguments. The argument, NonRootSafeAddr, has been added. When sendmail does not have enough privileges to run a .forward program or deliver to a file as the owner of that file, addresses are marked unsafe. Furthermore, if RunAsUser is set, users cannot use programs or deliver to files in their .forward programs. Use NonRootSafeAddr to resolve these problems. |
|
m4 name: confDOUBLE_BOUNCE_ADDRESS Argument: address. The default is postmaster. If an error occurs when sendmail is sending an error message, sendmail sends the “double-bounced” error message to the address that is specified by the argument to this option. |
|
m4 name: confFALLBACK_MX Argument: fully qualified domain name. This option now includes MX record lookups. To use the old behavior of no MX record lookups, you must put the name in square brackets. |
|
m4 name: confFAST_SPLIT Argument: number. The default value is one. This new option does the following: If the option is set to a value greater than zero, the initial MX lookups on addresses are suppressed when they are sorted, which might result in faster envelope splitting. If the mail is submitted from the command line, the value can limit the number of processes that are used to deliver the envelopes. If more envelopes are created, the envelopes are put in the queue and must be resolved with a queue run. |
|
m4 name: confLDAP_DEFAULT_SPEC Argument: Class switch with appropriate definition (for example, -hhost, -pport, -dbind DN). The new option allows a default map specification for LDAP maps. The assigned default settings are used for all LDAP maps unless other individual map specifications are made with the K command. Set this option before defining any LDAP maps. |
|
m4 name: confMAILBOX_DATABASE Argument: pw, which uses getpwnam(), is the default value. No other values are supported. The new option specifies the type of mailbox database that is used to check for local recipients. |
|
m4 name: confMAX_HEADERS_LENGTH Argument: number This option specifies a maximum length for the sum of all headers and can be used to prevent a denial-of-service attack. The default is 32768. A warning is issued if a value less than 16384 is used. You should not have to change the default value for the Solaris operating environment. |
|
m4 name: confMAX_MIME_HEADER_LENGTH Argument: number This option sets the maximum length of certain MIME header field values to x number of characters. Also, for parameters within headers, you can specify a maximum length of y. The combined values look like x/y. If y is not specified, half of x is used. If no values are set, the default is 0, which means no checks are made. This option is intended to protect mail user agents from buffer-overflow attacks. The suggested values are in the range of 256/128 to 1024/256. A warning is issued if values less than 128/40 are used. |
|
m4 name: confMAX_QUEUE_CHILDREN Argument: number This new option limits the number of concurrently active queue-runner processes to the number that is specified in the argument. The option helps to limit the system resources that are used when the queue is processed. When the total number of queue runners for multiple queue groups exceeds the defined argument, the remaining queue groups are run later. |
|
m4 name: confMAX_RCPTS_PER_MESSAGE Argument: number If this option is set, the option allows no more than the specified number of recipients in an SMTP envelope. The minimum argument is 100. You can still declare this option from both the command line and the configuration file. However, normal users can now set the option from the command line to enable the override of messages that are submitted through sendmail -bs. In this instance, sendmail does not relinquish its root privileges. |
|
m4 name: confMAX_RUNNERS_PER_QUEUE Argument: number. The default is one. Consider your resources carefully and do not set this value too high. This new option specifies the maximum number of queue runners per queue group. The queue runners work in parallel on a queue group's messages. This behavior is useful when the processing of a message might delay the processing of subsequent messages. |
|
m4 name: confNICE_QUEUE_RUN Argument: number This new option sets the priority of queue runners. Refer to the nice(1) man page. |
|
m4 name: confPID_file Argument: See Additional Arguments for the PidFile and ProcessTitlePrefix Options. This new option defines the location of the pid file. The file name is macro expanded before being opened. The default is /var/run/sendmail.pid. |
|
For details, see Changes to the PrivacyOptions Option. |
|
m4 name: confPROCESS_TITLE_PREFIX Argument: See Additional Arguments for the PidFile and ProcessTitlePrefix Options. The new option specifies a prefix string for the process title that is shown in /usr/ucb/ps auxww listings. The string is macro processed. You should not have to make any changes for the Solaris operating environment. |
|
m4 name: confQUEUE_FILE_MODE Argument: number This new option provides the default permissions in octal for queue files. If this option is not set, sendmail uses 0600. However, if the option's real and effective user ID is different, sendmail uses 0644. |
|
m4 name: confQUEUE_LA Argument: number The default value has changed from eight to eight times the number of processors online when the system starts. For single-processor machines, this change has no effect. Changing this value overrides the default and prevents the number of processors from being considered. Therefore, the effect of any value changes should be well understood. |
|
m4 name: confQUEUE_SORT_ORDER This option sets the algorithm that is used for sorting the queue. The default value is priority, which sorts the queue by message priority. Note the following changes. The host argument now reverses the host name before sorting, which means domains are grouped to run through the queue together. This improvement provides better opportunities for use of the connection cache, if available. The new filename argument sorts the queue by file name. This behavior avoids the opening and reading of each queue file when preparing to run the queue. The new modification argument sorts the queue by time of modification, starting with the oldest entries of the qf file. The new random argument sorts the queue randomly, which avoids contention, if several queue runners have manually been started. For more information, refer to QueueSortOrder in the sendmail(1M) man page. |
|
m4 name: confREFUSE_LA Argument: number The default value has changed from 12 to 12 times the number of processors online when the system starts. For single-processor machines, this change has no effect. A change of this value overrides the default and prevents the number of processors from being considered. Therefore, the effect of any value changes should be well understood. |
|
Two changes have been made. When attempting to canonify a host name, some name servers that are down return a temporary failure message, SERVFAIL, for IPv6 T_AAAA lookups. You can use this new argument, WorkAroundBrokenAAAA, to avoid this behavior. Also, the RES_USE_INET6 argument is controlled by a new flag, use_inet6. For more information, refer to the resolver(3RESOLV) man page. |
|
m4 name: confRRT_IMPLIES_DSN Argument: true or false If the new option is set, a “Return-Receipt-To:” header causes the request of a delivery status notification (DSN), which is sent to the envelope sender. The DSN is not sent to the address that is specified in the header. |
|
m4 name: confMIME_FORMAT_ERRORS Argument: true or false. The default is now true. |
|
m4 name: confSHARED_MEMORY_KEY Argument: number. This new option permits you to use shared memory, if shared memory is available, to store free space for queue file systems. This option minimizes the number of system calls to check for available space. |
|
m4 name: confSAFE_QUEUE Argument: true, false, or interactive. The default and recommended value is true. Avoid using false. If this option is set to true, the queue file is always instantiated, even if you are attempting immediate delivery. You can use the interactive value together with DeliveryMode=i to skip some synchronization calls that are doubled in the code execution path for this mode. |
|
For details, see Changes to the Timeout Option. |
|
m4 name: confTRUSTED_USER Argument: user name or user numeric ID. The new option enables you to specify a user name (instead of root) to own important files. If this option is set, generated alias databases and the control socket—if configured—are automatically owned by this user. This option requires HASFCHOWN. For information about HASFCHOWN, see Flags Used and Not Used to Compile sendmail. Only TrustedUser, root, and class t ($=t) users can rebuild the alias map. |
|
m4 name: confUSE_MSP Argument: true or false. The default is false. This new option permits group-writable queue files, if the group is the same as that of a set-group-id sendmail binary. In submit.cf, this option must be set to true. |
|
m4 name: confXF_BUFFER_SIZE Argument: number. The new option controls the maximum size (in bytes) of a memory-buffered transcript (xf) file before a disk-based file is used. The default is 4096 bytes. You should not have to change this default for the Solaris operating environment. |
Refer to the following table for a list of deprecated configuration file options. The table includes the AutoRebuildAliases option, which is not in version 8.12 of sendmail.
Table 24–3 Deprecated and Unsupported Configuration File Options for sendmail
Option |
Description |
---|---|
Because a denial-of-service attack could occur if this option is set, this option is not in version 8.12 of sendmail. Refer to the Release Notes that are part of the sendmail distribution at ftp://ftp.sendmail.org. A user could kill the sendmail process while the aliases file is being rebuilt and leave the file in an inconsistent state. Furthermore, because AutoRebuildAliases is not available, newaliases must be run manually now in order for changes to /etc/mail/aliases to become effective. Also, you must remember that because sendmail is no longer setuid root, only root can run newaliases. |
|
This option, which now defaults to True, has been deprecated. Refer to the Release Notes that are part of the sendmail distribution at ftp://ftp.sendmail.org. |
|
This option is deprecated. If required, you should now use the GroupWritableForwardFileSafe and GroupWritableIncludeFileSafe arguments for the DontBlameSendmail option. |
|
This option is deprecated. Furthermore, because this option violates RFC 1123, you should avoid using this option. |
The new ClientPortOptions option is for outgoing connections and is similar to the DaemonPortOptions option. This option sets the client SMTP options, which are a sequence of key=value pairs. To declare this option, use one of the following syntaxes. For formatting purposes, the example includes two pairs. However, you can apply one or more pairs.
O ClientPortOptions=pair,pair # for the configuration file -OClientPortOptions=pair,pair # for the command line define(`confCLIENT_OPTIONS',`pair,pair') # for m4 configuration |
If you need to build a new sendmail.cf file, refer to Building the sendmail.cf Configuration File (Task) in Chapter 22, Mail Services (Tasks).
The following table describes the new keys for this option.
Table 24–4 New Keys for ClientPortOptions
Key |
Description |
---|---|
Addr |
Specifies the address mask. The value can be a numeric address in dot notation or a network name. If the pair is omitted, the default is INADDR_ANY, which accepts connections from any network. |
Family |
Specifies the address family. The key's default is inet for AF_INET. Other values are inet6 for AF_INET6, iso for AF_ISO, ns for AF_NS, and x.25 for AF_CCITT. |
Listen |
Specifies the size of the listen queue. The key defaults to 10. You should not have to change this default for the Solaris operating environment. |
Port |
Specifies the name and number of the listening port. The key defaults to smtp. |
RcvBufSize |
Specifies the size of the TCP/IP send buffer. The key has no default value, which means that no size specifications are automatically made. If the option is set to a value that is greater than zero, that value is used. You should not have to limit the size of this buffer for the Solaris operating environment. |
Modifier |
Specifies flags for sendmail: The h flag uses the name that corresponds to the outgoing interface address for the HELO or EHLO commands, whether it was chosen by the connection parameter or by the default. The A flag disables AUTH. This flag can also be used with the Modifier key for DaemonPortOptions. Refer to Changes to DaemonPortOptions Option. The S flag turns off the use of or the offer to use STARTTLS when email is being delivered or is being received. |
The following tables describe the new features.
Table 24–5, New and Revised Keys for DaemonPortOptions
Table 24–6, Values for the New Modifier Key
To declare this option, use one of the following syntaxes. In the example, pair refers to key=value. For formatting purposes, the example includes two pairs. However, you can apply one or more pairs.
O DaemonPortOptions=pair,pair # for the configuration file -ODaemonPortOptions=pair,pair # for the command line define(`confDAEMON_OPTIONS',`pair,pair') # for m4 configuration |
To avoid security risks, sendmail relinquishes its root permissions when you set this option from the command line.
If you need to build a new sendmail.cf file, refer to Building the sendmail.cf Configuration File (Task) in Chapter 22, Mail Services (Tasks).
The following table describes new and revised keys for the DaemonPortOptions option.
Table 24–5 New and Revised Keys for DaemonPortOptions
Key |
Description |
---|---|
Name |
A new key that specifies a user-definable name for sendmail. This key is used for error messages and for logging. The default is MTA. |
Modifier |
A new key that specifies values for sendmail that can be listed in a sequence without delimiters. For a list of values, see Table 24–6. |
Family |
Unless a Family is specified in a DaemonPortOptions option, inet is now the only default. If IPv6 users also want to listen on IPv6 interfaces, they can configure additional sockets into sendmail.cf by adding a Family=inet6 setting to a DaemonPortOptions option. |
The following table describes the values for the new Modifier key.
Table 24–6 Values for the New Modifier Key
Value |
Description |
---|---|
A |
Disables AUTH by overriding the Modifier value of a. Can be used with the Modifier key for ClientPortOptions. Refer to New ClientPortOptions Option. |
C |
Does not perform host-name canonification. |
E |
Disallows the ETRN command. |
O |
Ignores the socket if a failure should occur. |
S |
Turns off the use or the offer to use STARTTLS when email is being delivered or is being received. Can be used with the Modifier key for ClientPortOptions. |
a |
Requires authentication. |
b |
Binds to the interface that receives the mail. |
c |
Performs host-name canonification. Use this value only in configuration file declarations. |
f |
Requires fully qualified host names. Use this value only in configuration file declarations. |
h |
Uses the interface's name for the outgoing HELO command. |
u |
Allows unqualified addresses. Use this value only in configuration file declarations. |
The following table describes additional macro-processed arguments for the PidFile and ProcessTitlePrefix options. For more information about these options, see Table 24–2.
Table 24–7 Arguments for the PidFile and ProcessTitlePrefix Options
Macro |
Description |
---|---|
${daemon_addr} |
Provides daemon address (for example, 0.0.0.0) |
${daemon_family} |
Provides daemon family (for example, inet, and inet6) |
${daemon_info} |
Provides daemon information (for example, SMTP+queueing@00:30:00) |
${daemon_name} |
Provides daemon name (for example, MSA) |
${daemon_port} |
Provides daemon port (for example, 25) |
${queue_interval} |
Provides queue run interval (for example, 00:30:00) |
New and revised arguments for PrivacyOptions (popt) are described in the following table. You can declare this option from the command line without sendmail relinquishing its root privilege. To declare this sendmail option, use one of the following syntaxes.
O PrivacyOptions=argument # for the configuration file -OPrivacyOptions=argument # for the command line define(`confPRIVACY_FLAGS',`argument') # for m4 configuration |
If you need to build a new sendmail.cf file, refer to Building the sendmail.cf Configuration File (Task) in Chapter 22, Mail Services (Tasks).
The following table provides descriptions of new and revised arguments for the PrivacyOptions option.
Table 24–8 New and Revised Arguments for PrivacyOptions
Argument |
Description |
---|---|
goaway |
This argument no longer accepts the following flags: noetrn, restrictmailq, restrictqrun, restrictexpand, nobodyreturn, and noreceipts. |
nobodyreturn |
This argument instructs sendmail not to include the body of the original message in delivery status notifications. |
noreceipts |
When this argument is set, delivery status notification (DSN) is not announced. |
restrictexpand |
This argument instructs sendmail to drop privileges when the -bv option is given by users who are neither root nor TrustedUser. The users cannot read private aliases, .forward files, or :include: files. This argument also overrides the -v command-line option. |
The following table provides information about the changes to the Timeout option. Specifically, this sendmail option has some new keywords and a new value for ident. In the Solaris operating environment, you should not need to change the default values for the keywords that are listed in the table. However, if you choose to make a change, use the keyword=value syntax. The value is a time interval. Refer to the following examples.
O Timeout.keyword=value # for the configuration file -OTimeout.keyword=value # for the command line define(`m4_name', value) # for m4 configuration |
If you need to build a new sendmail.cf file, refer to Building the sendmail.cf Configuration File (Task) in Chapter 22, Mail Services (Tasks).
To avoid security risks, sendmail relinquishes its root permissions when you set this option from the command line.
Keyword |
Default Value |
Description |
---|---|---|
aconnect |
0 |
m4 name: confTO_ACONNECT Limits the total time to wait for all connections to succeed for a single delivery attempt. The maximum value is unspecified. |
control |
2m |
m4 name: confTO_CONTROL Limits the total time that is dedicated to completing a control socket request. |
ident |
5s |
m4 name: confTO_IDENT Defaults to 5 seconds—instead of 30 seconds—to prevent the common delays that are associated with mailing to a site that drops IDENT packets. No maximum value is specified. |
lhlo |
2m |
m4 name: confTO_LHLO Limits the time to wait for a reply from an LMTP LHLO command. No maximum value is specified. |
queuereturn |
5d |
m4 name: confTO_QUEUERETURN Includes the value now, which immediately bounces entries from the queue without a delivery attempt. |
resolver.retrans |
varies |
m4 name: confTO_RESOLVER_RETRANS Sets the resolver's retransmission time interval in seconds, which applies to resolver.retrans.first and resolver.retrans.normal. |
resolver.retrans.first |
varies |
m4 name: confTO_RESOLVER_RETRANS_FIRST Sets the resolver's retransmission time interval in seconds for the first attempt to deliver a message. |
resolver.retrans.normal |
varies |
m4 name: confTO_RESOLVER_RETRANS_NORMAL Sets the resolver's retransmission time interval in seconds for all resolver lookups, except the first delivery attempt. |
resolver.retry |
varies |
m4 name: confTO_RESOLVER_RETRY Sets the number of times to retransmit a resolver query, which applies to Timeout.resolver.retry.first and Timeout.resolver.retry.normal. |
resolver.retry.first |
varies |
m4 name: confTO_RESOLVER_RETRY_FIRST Sets the number of times to retransmit a resolver query for the first attempt to deliver a message. |
resolver.retry.normal |
varies |
m4 name: confTO_RESOLVER_RETRY_NORMAL Sets the number of times to retransmit a resolver query for all resolver lookups, except the first delivery attempt. |
The following table describes new macros that are reserved for use by the sendmail program. The macros' values are assigned internally. For more information, refer to the sendmail(1M) man page.
Table 24–10 Defined Macros for sendmail
Macro |
Description |
---|---|
${addr_type} |
Identifies the current address as an envelope sender or a recipient address. |
${client_resolve} |
Holds the result of the resolve call for ${client_name}: OK, FAIL, FORGED, or TEMP. |
${deliveryMode} |
Specifies the current delivery mode sendmail is using instead of the value of the DeliveryMode option. |
${dsn_notify}, ${dsn_envid}, ${dsn_ret} |
Holds the corresponding DSN parameter values. |
${if_addr} |
Provides the interface's address for the incoming connection if the interface does not belong to the loopback net. This macro is especially useful for virtual hosting. |
${if_addr_out}, ${if_name_out}, ${if_family_out} |
Avoids the reuse of ${if_addr}. Holds the following values respectively. The address of the interface for the outgoing connection The host name of the interface for the outgoing connection The family of the interface for the outgoing connection |
${if_name} |
Provides the interface's host name for the incoming connection and is especially useful for virtual hosting. |
${load_avg} |
Checks and reports the current average number of jobs in the run queue. |
${msg_size} |
Holds the value of the message size (SIZE=parameter) in an ESMTP dialogue before the message has been collected. Thereafter, the macro holds the message size as computed by sendmail and is used in check_compat. For information about check_compat, refer to Table 24–14. |
${nrcpts} |
Holds the number of validated recipients. |
${ntries} |
Holds the number of delivery attempts. |
${rcpt_mailer}, ${rcpt_host}, ${rcpt_addr}, ${mail_mailer}, ${mail_host}, ${mail_addr} |
Holds the results of parsing the RCPT and MAIL arguments, which is the resolved right-hand side (RHS) triplet from the mail delivery agent ($#mailer), the host ($@host), and the user ($:addr). |
In this section, you can find the following.
Table 24–11, New Macros Used to Build the sendmail Configuration File
Macro |
Description |
---|---|
LOCAL_MAILER_EOL |
Overrides the default end-of-line string for the local mailer. |
LOCAL_MAILER_FLAGS |
Adds Return-Path: header by default. |
MAIL_SETTINGS_DIR |
Contains the path (including the trailing slash) for the mail settings directory. |
MODIFY_MAILER_FLAGS |
Improves the *_MAILER_FLAGS. This macro sets, adds, or deletes flags. |
RELAY_MAILER_FLAGS |
Defines additional flags for the relay mailer. |
Use the following new macros to configure the maximum number of commands that can be received before sendmail slows its delivery. You can set these MAX macros at compile time. The maximum values in the following table also represent the current default values.
Table 24–12 New MAX Macros
Macro |
Maximum Value |
Commands Checked by Each Macro |
---|---|---|
25 |
Unknown commands |
|
20 |
NOOP, VERB, ONEX, XUSR |
|
3 |
HELO, EHLO |
|
6 |
VRFY, EXPN |
|
8 |
ETRN |
You can disable a macro's check by setting the macro's value to zero.
This section contains a table of new and revised m4 configuration macros for sendmail. Use the following syntax to declare these macros.
symbolic_name(`value') |
If you need to build a new sendmail.cf file, refer to Building the sendmail.cf Configuration File (Task) in Chapter 22, Mail Services (Tasks).
Table 24–13 New and Revised m4 Configuration Macros for sendmail
m4 Macro |
Description |
---|---|
FEATURE() |
For details, refer to Changes to the FEATURE() Declaration. |
This macro adds entries to class w ($=w). |
|
A new macro that defines hosts or subdomains that cannot be masqueraded. |
|
This macro can now be used for bracketed addresses, such as user@[host]. |
|
When these macros are used, include $={VirtHost} in $=R. As a reminder, $=R is the set of host names that are allowed to relay. |
Refer to the following tables for information about the specific changes to the FEATURE() declarations.
Table 24–14, New and Revised FEATURE() Declarations
Table 24–15, Unsupported FEATURE() Declarations
To use the new and revised FEATURE names, use the following syntax.
FEATURE(`name', `argument') |
If you need to build a new sendmail.cf file, refer to Building the sendmail.cf Configuration File (Task) in Chapter 22, Mail Services (Tasks).
Table 24–14 New and Revised FEATURE() Declarations
Name of FEATURE() |
Description |
---|---|
Argument: Refer to the example in the following paragraph. This new FEATURE() enables you to look for a key in the access map that consists of the sender address and the recipient address. This FEATURE() is delimited by the following string, <@>. sender@sdomain<@>recipient@rdomain is an example. |
|
Argument: friend, which enables a spam-friend test, or hater, which enables a spam-hater test. A new FEATURE() that delays all checks. By using FEATURE(`delay_checks'), the rule sets check_mail and check_relay are not called when a client connects or issues a MAIL command, respectively. Instead, these rule sets are called by the check_rcpt rule set. For details, refer to the /usr/lib/mail/README file. |
|
Argument: This FEATURE()accepts a maximum of two arguments:
A new FEATURE() that you can include multiple times to check the return values for DNS lookups. Note that this FEATURE() enables you to specify the behavior of temporary lookup failures. |
|
Argument: domain name. A new FEATURE() that is an enhanced version of dnsbl, which enables you to check the return values for DNS lookups. For more information, refer to /usr/lib/mail/README. |
|
Argument: None. A new FEATURE() that you can also use to apply genericstable to subdomains of $=G. |
|
Argument: For details, refer to the “Release Notes” in http://www.sendmail.org. A new FEATURE() that implements LDAP address routing. |
|
Argument: Path name of an LMTP-capable mailer. The default is mail.local, which is LMTP capable in this Solaris release. A FEATURE() that now sets the delivery status notification (DSN) diagnostic-code type for the local mailer to the proper value of SMTP. |
|
Argument: None. A new FEATURE() that you can use to avoid masquerading for the local mailer. |
|
Argument: None. A new FEATURE() that you can also use to look up the .domain in the access map. |
|
Argument: canonify_hosts or nothing. A FEATURE() that now includes the following features. Enables a list of domains, as specified by CANONIFY_DOMAIN or CANONIFY_DOMAIN_FILE, to be passed to the $[ and $] operators for canonification. Enables addresses that have only a host name, such as <user@host>, to be canonified, if canonify_hosts is specified as its parameter. Adds a trailing dot to addresses with more than one component. |
|
Argument: None. A new FEATURE() that turns off sendmail's default setting from m4–generated configuration files to “listen” on several different ports, an implementation of RFC 2476. |
|
Argument: reject, which does not allow the ! token, or nospecial, which does allow the ! token. A FEATURE() that determines whether to allow the ! token in the local part of an address. |
|
Argument: None. A FEATURE() that now provides the full rule sets of a normal configuration, allowing anti-spam checks to be performed. |
|
Argument: None. A new FEATURE() that enables you to preserve the +detail portion of the address when sendmail passes the address to the local delivery agent. |
|
Argument: None. A new FEATURE() that enables you to preserve the name of the recipient host, if LUSER_RELAY is used. |
|
Argument: None. A new FEATURE() that enables you to select a queue group that is based on the full email address or on the domain of the recipient. |
|
Argument: The domain is an optional argument. A new FEATURE() that allows relaying if the mail sender is listed as a RELAY in the access map and is tagged with the From: header line. If the optional domain argument is given, the domain portion of the mail sender is also checked. |
|
Argument: None. A FEATURE() that you can now use to apply $={VirtHost}, a new class for matching virtusertable entries that can be populated by VIRTUSER_DOMAIN or VIRTUSER_DOMAIN_FILE. FEATURE(`virtuser_entire_domain') can also apply the class $={VirtHost} to entire subdomains. |
The following FEATURE() declarations are no longer supported.
Table 24–15 Unsupported FEATURE() Declarations
The MAILER() declaration specifies support for delivery agents. To declare a delivery agent, use the following syntax.
MAILER(`symbolic_name') |
Note the following changes.
In this new version of sendmail, the MAILER(`smtp') declaration now includes an additional mailer, dsmtp, which provides on-demand delivery by using the F=% mailer flag. The dsmtp mailer definition uses the new DSMTP_MAILER_ARGS, which defaults to IPC $h.
Numbers for rule sets that are used by MAILERs have been removed. You now have no required order for listing your MAILERs except for MAILER(`uucp'), which must follow MAILER(`smtp') if uucp-dom and uucp-uudom are used.
For more information about mailers, refer to Mailers. If you need to build a new sendmail.cf file, refer to Building the sendmail.cf Configuration File (Task) in Chapter 22, Mail Services (Tasks).
The following table describes new delivery agent flags, which by default are not set. These single-character flags are Boolean. You can set or unset a flag by including or excluding it in the F= statement of your configuration file, as shown in the following example.
Mlocal, P=/usr/lib/mail.local, F=lsDFMAw5:/|@qSXfmnz9, S=10/30, R=20/40, Mprog, P=/bin/sh, F=lsDFMoqeu9, S=10/30, R=20/40, D=$z:/, Msmtp, P=[IPC], F=mDFMuX, S=11/31, R=21, E=\r\n, L=990, Mesmtp, P=[IPC], F=mDFMuXa, S=11/31, R=21, E=\r\n, L=990, Msmtp8, P=[IPC], F=mDFMuX8, S=11/31, R=21, E=\r\n, L=990, Mrelay, P=[IPC], F=mDFMuXa8, S=11/31, R=61, E=\r\n, L=2040, |
Flag |
Description |
---|---|
% |
Mailers that use this flag do not attempt delivery to the initial recipient of a message or to queue runs unless the queued message is selected by using an ETRN request or one of the following queue options: -qI, -qR, or -qS. |
1 |
This flag disables the ability of the mailer to send null characters (for example, \0). |
2 |
This flag disables the use of ESMTP and requires that SMTP be used instead. |
6 |
This flag enables mailers to strip headers to 7 bit. |
The following table describes new equates that you can use with the M delivery agent definition command. The following syntax shows you how to append new equates or new arguments to the equates that already exist in the configuration file.
Magent_name, equate, equate, ... |
The following example includes the new W= equate. This equate specifies the maximum time to wait for the mailer to return after all data has been sent.
Msmtp, P=[IPC], F=mDFMuX, S=11/31, R=21, E=\r\n, L=990, W=2m |
When you modify the definition of a value for m4 configuration, use the syntax that is provided in the following example.
define(`SMTP_MAILER_MAXMSGS', `1000') |
The preceding example places a limit of 1000 on the number of messages that are delivered per connection on an smtp mailer.
If you need to build a new sendmail.cf file, refer to Building the sendmail.cf Configuration File (Task) in Chapter 22, Mail Services (Tasks).
Typically, you modify the equate definitions in the mailer directory only when you fine-tune.
The following list provides details about new queue features.
This release supports multiple queue directories. To use multiple queues, supply a QueueDirectory option value in the configuration file that ends with an asterisk (*), as is shown in the following example.
O QueueDirectory=/var/spool/mqueue/q* |
The option value, /var/spool/mqueue/q*, uses all of the directories (or symbolic links to directories) that begin with “q” as queue directories. Do not change the queue directory structure while sendmail is running. Queue runs create a separate process for running each queue unless the verbose flag (-v) is used on a non-daemon queue run. The new items are randomly assigned to a queue.
The new queue file-naming system uses file names that are guaranteed to be unique for 60 years. This system allows queue IDs to be assigned without complex file-system locking and simplifies the movement of queued items between queues.
In version 8.12 of sendmail, only root can run the mail queue. For further details, refer to the changes that are described in the mailq(1) man page. For new task information, refer to Administering the Queue Directories (Task Map).
To accommodate envelope splitting, queue file names are now 15–characters long, rather than 14–characters long. File systems with a 14–character name limit are no longer supported.
For task information, refer to Administering the Queue Directories (Task Map).
The following list describes changes in the use of the Lightweight Directory Access Protocol (LDAP) with sendmail.
LDAPROUTE_EQUIVALENT() and LDAPROUTE_EQUIVALENT_FILE() permit you to specify equivalent host names, which are replaced by the masquerade domain name for LDAP routing lookups. For more information, refer to /usr/lib/mail/README.
As noted in the Release Notes that are part of the sendmail distribution at ftp://ftp.sendmail.org, the LDAPX map has been renamed to LDAP. Use the following syntax for LDAP.
Kldap ldap options |
This release supports the return of multiple values for a single LDAP lookup. Place the values to be returned in a comma-separated string with the -v option, as is shown.
Kldap ldap -v"mail,more_mail" |
If no LDAP attributes are specified in an LDAP map declaration, all attributes that are found in the match are returned.
This version of sendmail prevents commas in quoted key and value strings in the specifications of the LDAP alias file from dividing a single entry into multiple entries.
This version of sendmail has a new option for LDAP maps. The option, –Vseparator enables you to specify a separator, so that a lookup can return both an attribute and a value that are separated by the relevant separator.
Instead of using the %s token to parse an LDAP filter specification, you can also use the new token, %0, to encode the key buffer. The %0 token applies a literal meaning to LDAP special characters.
The following example shows how these tokens differ for a “*” lookup.
Table 24–18 Comparison of Tokens
LDAP Map Specification |
Specification Equivalent |
Result |
---|---|---|
-k"uid=%s" |
-k"uid=*" |
Matches any record with a user attribute |
-k"uid=%0" |
-k"uid=\2A" |
Matches a user with the name “*” |
The following table describes new LDAP map flags.
Table 24–19 New LDAP Map Flags
Flag |
Description |
---|---|
-1 |
Requires a single match to be returned. If more than one match is returned, the results are the equivalent of no records being found. |
-r never|always|search|find |
Sets the LDAP alias dereference option. |
-Z size |
Limits the number of matches to return. |
The old [TCP] built-in mailer is not available. Use the P=[IPC] built-in mailer instead. The interprocess communications ([IPC]) built-in mailer now enables delivery to a UNIX domain socket on systems that support it. You can use this mailer with LMTP delivery agents that listen on a named socket. An example mailer might resemble the following.
Mexecmail, P=[IPC], F=lsDFMmnqSXzA5@/:|, E=\r\n, S=10, R=20/40, T=DNS/RFC822/X-Unix, A=FILE /var/run/lmtpd |
The first mailer argument in the [IPC] mailer is now checked for a legitimate value. The following table provides possible values for the first mailer argument.
Table 24–20 Possible Values for the First Mailer Argument
Value |
Description |
---|---|
A=FILE |
Use for UNIX domain socket delivery |
A=TCP |
Use for TCP/IP connections |
A=IPC |
Is no longer available as a first mailer argument |
The following table lists the new rule sets and describes what the rule sets do.
Table 24–21 New Rule Sets
Set |
Description |
---|---|
Correlates information that is gathered between headers and checks for missing headers. This rule set is used with the macro storage map and is called after all of the headers have been collected. |
|
Uses the ETRN command (as check_rcpt uses RCPT). |
|
Uses the EXPN command (as check_rcpt uses RCPT). |
|
Uses the VRFY command (as check_rcpt uses RCPT). |
The following list describes new rule set features.
Numbered rule sets are also named, but the rule sets can still be accessed by their numbers.
The H header configuration file command allows for a default rule set to be specified for header checks. This rule set is called only if the individual header has not been assigned its own rule set.
Comments in rule sets (that is, text within parentheses) are not removed if the configuration file version is nine or greater. For example, the following rule matches the input token (1), but does not match the input token.
R$+ (1) $@ 1 |
sendmail accepts the SMTP RSET command even when it rejects commands because of TCP wrappers or the check_relay rule set.
You receive a warning if you set the OperatorChars option multiple times. Also, do not set OperatorChars after the rule sets are defined.
The name of the rule set, as well as its lines, are ignored if an invalid rule set is declared. The rule set lines are not added to S0.
The helpfile is now located in /etc/mail/helpfile. The old name (/etc/mail/sendmail.hf) has a symbolic link that points to the new name.
The trusted-users file is now located in /etc/mail/trusted-users. During an upgrade, if the old name (/etc/mail/sendmail.ct) is detected, but not the new name, a hard link from the old name to the new name is created. Otherwise, no change is made. The default content is root.
The local-host-names file is now located in /etc/mail/local-host-names. During an upgrade, if the old name (/etc/mail/sendmail.cw) is detected, but not the new name, a hard link from the old name to the new name is created. Otherwise, no change is made. The default content is zero length.
The new name for /usr/lib/mail/cf/main-v7sun.mc is /usr/lib/mail/cf/main.mc.
The new name for /usr/lib/mail/cf/subsidiary-v7sun.mc is /usr/lib/mail/cf/subsidiary.mc.
In version 8.12 of sendmail, IPv6 addresses that are used in configuration should be prefixed with the IPv6: tag to identify the address properly. If you are not identifying an IPv6 address, a prefix tag is not used.
The following table describes the new command-line options for the mail.local program, which is used by sendmail as a delivery agent for local mail.
Table 24–22 New Command-Line Options for mail.local
Option |
Description |
---|---|
-7 |
Prevents the Local Mail Transfer Protocol (LMTP) mode from advertising 8BITMIME support in the LHLO response |
-b |
Causes a permanent error instead of a temporary error if a mailbox exceeds its quota |
mail.local is the default for LMTP mode. However, for this release, if you choose to use mail.local as the local delivery agent without being in LMTP mode, you need to do one of the following to set the S flag.
Use the following syntax for the configuration file.
MODIFY_MAILER_FLAGS(`LOCAL', `+S') # for the configuration file |
Alternately, perform the following two steps for m4 configuration.
define(`MODIFY_MAILER_FLAGS', `S')dnl # first step MAILER(local)dnl # second step |
MODIFY_MAILER_FLAGS is a new macro that is used to build the configuration file. For details, refer to New Macros Used to Build the sendmail Configuration File.
For a complete review, refer to the mail.local(1M) man page.
The mailstats program, which provides statistics on mailer usage, is packaged with the sendmail program. The following table describes new options in mailstats.
Table 24–23 New mailstats Options
Option |
Description |
---|---|
-C filename |
Specifies a sendmail configuration file |
-p |
Provides clear statistics in a program-readable mode |
-P |
Also provides clear statistics in a program-readable mode, but this option does not truncate the statistics file |
For more information, refer to the mailstats(1) man page.
The makemap command creates keyed database files for sendmail. The following table describes new makemap options. When you declare options, use the following syntax.
makemap options class filename |
When you use the preceding syntax, remember the following.
options are preceded by a dash (for example, -dN).
class refers to the type of database (for example, btree, dbm, or hash).
filename refers to the full path (or relative name) for the database file.
Option |
Description |
---|---|
-C |
Uses the specified sendmail configuration file for finding the TrustedUser option |
-c |
Uses the specified hash and btree cache size |
-e |
Allows an empty value from the right-hand side (RHS) |
-l |
Lists map types that are supported |
-t |
Specifies a different delimiter, instead of white space |
-u |
Dumps (unmaps) the contents of the database to standard output |
If makemap is running as root, the ownership of the generated maps is automatically changed to the TrustedUser, as specified in the sendmail configuration file. For more information about the TrustedUser option, refer to Table 24–2.
For more information, refer to the makemap(1M) man page.
Use the new maintenance command, editmap, to query and edit single records in keyed database maps for sendmail. From the command line, use the following syntax.
editmap options maptype mapname key "value" |
options are preceded by a dash (for example, -Nf). The man page provides a list of options and explains how each option functions.
maptype refers to the type of database. editmap can use btree, dbm, and hash.
mapname refers to the full path or relative name for the database file.
key refers to a single string or multitoken string that you can use for searches.
“value” refers to the string that appears to the right of the key in a keyed database file. In the following example, man is the key and man@example.com is the assigned value for that key.
man man@host.com |
For a detailed description and a list of options, refer to the editmap(1M) man page.
The following list describes other changes and features of interest.
As noted in RFC 2476, sendmail now listens for submissions on port 587.
As was noted in the Release Notes that are part of the sendmail distribution at ftp://ftp.sendmail.org, the XUSR SMTP command is deprecated. Mail user agents should begin using RFC 2476 Message Submission for initial user message submission.
The Content-Length: header is no longer provided in messages that are piped to programs with any version of the Sun configuration files. However, this header is still provided for ordinary mailbox deliveries that use any version of the Sun configuration files.
sendmail now accepts connections when disk space is low, but in such situations it allows only ETRN commands.
Entries in the alias file can be continued by putting a backslash directly before the new line.
The timeout for sending a message by way of SMTP has been changed to check for delivery progress every five minutes. This change detects an inability to send information more quickly and reduces the number of processes that are waiting to time out.
You can now copy the contents of a class to another class by using the syntax of the following example.
C{Dest} $={Source} |
In the preceding example, all items in class $={Source} are copied into class $={Dest}.
The maps are no longer optional by default. Also, if a problem occurs with a map, you receive an error message.
Canonification is no longer attempted for any host or domain in class P ($=P).
The = equate is not included in an option expansion if no value is associated with the option.
Route addresses are stripped. For example, <@a,@b,@c:user@d> is converted to <user@d>.