System Administration Guide, Volume 3

Chapter 34 Setting Up and Administering Mail Services

This chapter describes how to set up and administer mail services. If you are not familiar with administering mail services, read Chapter 33, Introduction to Mail Services for an introduction to the terminology and structure of the mail services and for descriptions of several mail service configurations.

Planning Your Mail System

This section describes four basic types of mail configurations and briefly outlines the tasks required to set up each configuration. You might find this section useful if you need to set up a new mail system or if you are expanding an existing one. The configurations start with the most basic case (mail completely local, no connection to the outside world) and increase in complexity to a two-domain configuration with a mail gateway. The first decision you should make is which one of these configurations you would like to employ. The following configurations are covered:

As system administrator, you should decide on a policy for updating aliases and for forwarding mail messages. You might set up an aliases mailbox as a place for users to send requests for mail forwarding and for changes to their default mail alias. If your system uses NIS or NIS+, you can administer forwarding rather than forcing users to manage it themselves.

Local Mail Only

The simplest mail configuration, shown in Figure 34-1, is one mail host with two or more workstations connected to it. Mail is completely local. All the clients store mail on their local disks and act as mail servers. Mail addresses are parsed using the /etc/mail/aliases files.

Figure 34-1 Local Mail Configuration

Graphic

To set up this kind of mail configuration, you need:

Local Mail in Remote Mode

In this configuration, each mail client mounts its mail from one mail server that provides mail spooling for client mailboxes. This server can also be the mail host. This configuration assists the backup of the mailboxes for each client.

To set up this kind of mail configuration, you need:

Local Mail and a Remote Connection

The most common mail configuration in a small network is shown in Figure 34-2. One system is the mail server, the mail host, and the mail gateway to the outside world. Mail is distributed using the /etc/mail/aliases files. No name service is required.

Figure 34-2 Local Mail Configuration With a UUCP Connection

Graphic

To set up this kind of a mail configuration, assuming that the mail clients mount their mail files from /var/mail on the mail host, you need:

Two Domains and a Gateway

The mail configuration shown in Figure 34-3 has two domains and a mail gateway. In this configuration, the mail server, the mail host, and the mail gateway (or gateways) for each domain are likely to be different systems. To assist the process of administering and distributing mail, a name service is used.

Figure 34-3 Two Domains and a Gateway

Graphic

To set up this kind of a mail configuration, assuming that the mail clients mount their mail files from /var/mail on the mail host, you need:

Setting Up Mail Services

You can readily set up a mail service if your site does not provide connections to electronic mail (email) services outside your company or if your company is in a single domain.

Mail requires two types of configurations for local mail and two more for communication with networks outside of your domain. You can combine these configurations on the same system or provide them on separate systems. You need to set up systems on your site to perform the functions described in:

Before you begin to set up your mail service, choose the systems to act as mail servers, mail hosts, and mail gateways. You should also make a list of all the mail clients for which you are providing service and include the location of their mailboxes. This list will help you when you are ready to create mail aliases for your users. See Chapter 33, Introduction to Mail Services for more information about the function each of these systems provides. For your convenience, guidelines about which systems are good candidates for mail server, mail host, and mail gateways are repeated in the following sections.

To simplify the setup instructions, this chapter tells you what you need to do to set up individual mail servers, mail hosts, mail clients, and relay hosts. If a system in your mail services configuration is acting in more than one capacity, follow the appropriate instructions for each type of system. For example, if your mail host and mail server functions are on the same system, follow the directions for setting up that system as a mail host and then follow the directions for setting up the same system as a mail server.


Note -

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--in which case the following procedures are not needed.


How to Set Up a Mail Server

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 name space, and the user should have a local home directory (so that ~/.forward can be checked) for mail to be delivered. This is why home directory servers are often set up as the mail server.

The mail server can route all mail for many mail clients. The only resource requirement for this type of mail server is that it have adequate spooling space for client mailboxes. The /var/mail directory must be made available for remote mounting.

For this task, check that /etc/dfs/dfstab file shows the /var/mail directory is exported.

  1. Become superuser on the mail server.

  2. Check that the /var/mail directory is available for remote access.

    Type share and press Return. If the /var/mail directory is listed, you do not need to do more. If the /var/mail directory is not listed, continue with the next step.

  3. Make the /var/mail directory available for remote access.

    Type the following command:


    # share -F nfs /var/mail
    
  4. Make the file system permanently available for remote access.

    Edit /etc/dfs/dfstab and add the command line used in step 2.


    # cat /etc/dfs/dfstab
     ..
    share -F nfs -o rw /var/mail

Note -

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.


How to Set Up a Mail Client

A mail client is a user of mail services, with a mailbox on a mail server, and a mail alias in the /etc/mail/aliases file that points to the location of the mailbox.

  1. Become superuser on the mail client's system.

  2. Make sure a /var/mail mount point exists on the mail client's system.

    Using ls tells you if the file system exists. The following example shows the response if the file system has not been created.


    # ls -l /var/mail
    /var/mail not found

    If mail files are in this directory, you should probably move them, so that they are not covered when the /var/mail directory is mounted from the server.

  3. Mount the /var/mail directory from the mail server.

    The mail directory can be automatically mounted or mounted at boot time.

    1. (Optional) Mount /var/mail automatically.

      Edit /etc/auto_direct and add an entry like this one:


      /var/mail -rw,hard,actimeo=0 server:/var/mail
    2. (Optional) Mount /var/mail at boot time.

      Edit the /etc/vfstab file and add an entry for the /var/mail directory on the mail server, mounting it on the local /var/mail directory.


      server:/var/mail - /var/mail nfs - no rw,hard,actimeo=0

      The client's mailbox is automatically mounted any time the system is rebooted. Type mountall to mount the client mailbox until the system is rebooted.


      Caution - Caution -

      You must include the actimeo=0 option when mounting mail from an NFS server to allow mailbox locking and access to work properly.


  4. Update/etc/hosts.

    Use admintool to 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.

  5. Add an entry for the client to one of the alias files.

    See "Administering Mail Alias Files" for information about how to create mail aliases for different kinds of mail configurations.


    Note -

    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.


  6. Restart sendmail.

How to Set Up a Mail Host

A mail host resolves email addresses and reroutes mail within your domain. A good candidate for a mail host is a system that connects your systems to the outside world or to a parent domain.

  1. Become superuser on the mail host system.

  2. Verify the host name configuration.

    Run the check-hostname script to verify if sendmail will be able to identify the fully qualified host name for this server:


    % /usr/lib/mail/sh/check-hostname
    hostname phoenix OK: fully qualified as phoenix.eng.acme.com

    If this script is not successful in identifying the fully qualified host name, you need to add the fully qualified hos tname as the first alias for the host in /etc/hosts.

  3. Update/etc/hosts.

    Use admintool to edit the /etc/hosts file. Add the word mailhost and mailhost.domainname after the IP address and system name of the mail host system. The system is designated as a mail host. The domainname should be identical to the string given as the subdomain name in the output of the following command:


    % /usr/lib/sendmail -bt -d0 </dev/null
    Version 8.9.0+Sun
     Compiled with: MAP_REGEX LOG MATCHGECOS MIME7TO8 MIME8TO7 NAMED_BIND 
                    NDBM NETINET NETUNIX NEWDB NIS NISPLUS QUEUE SCANF SMTP
                    USERDB XDEBUG
    
    ============ SYSTEM IDENTITY (after readcf) ============
          (short domain name) $w = phoenix
      (canonical domain name) $j = phoenix.eng.acme.com
             (subdomain name) $m = eng.acme.com
                  (node name) $k = phoenix
    ========================================================

    Here is an example of how the hosts file should look after these changes:


    # cat /etc/hosts
    #
    # Internet host table
    #
    127.0.0.1       localhost        
    129.0.0.1       phoenix mailhost mailhost.eng.acme.com        loghost
  4. Create an entry for the new mail host in the appropriate hosts file.

    If you are using NIS or NIS+, add an entry including a host alias called mailhost and mailhost.domainname to the host entry for the new mail host.

    If you are not using NIS or NIS+, you must create an entry in /etc/hosts for each system on the network. The entry should use this format: IP_address mailhost_name mailhost mailhost.domainname

  5. Change the correct configuration file.

    This command copies and renames the /etc/mail/main.cf file.


    # cp /etc/mail/main.cf /etc/mail/sendmail.cf
    
  6. Restart sendmail and test your mail configuration.

    See "How to Test the Mail Configuration" for information.

How to Set Up a Mail Gateway

A mail gateway manages communication with networks outside of 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 attached to Ethernet and phone lines or a system configured as a router to the Internet. You might want to configure the mail host or another system as mail gateway. You might choose to configure more than one mail gateway for your domain. If you have UUCP connections, you should configure the system (or systems) with UUCP connections as the mail gateway.

  1. Become superuser on the mail gateway.

  2. Change the configuration file.

    The following command copies and renames the main.cf file.


    # cp /etc/mail/main.cf /etc/mail/sendmail.cf
    
  3. Verify the host name configuration.

    Run the check-hostname script to verify if sendmail will be able to identify the fully qualified host name for this server:


    # /usr/lib/mail/sh/check-hostname
    hostname phoenix OK: fully qualified as phoenix.eng.acme.com

    If this script is not successful in identifying the fully qualified hos tname, you need to add the fully qualified host name as the first alias for the host in /etc/hosts.

  4. Restart sendmail and test your mail configuration.

    See "How to Test the Mail Configuration" for information.

How to Use DNS With sendmail

The DNS name service does not support aliases for individuals. It does support aliases for hosts or domains using mail exchange (MX) records and cname records. You can specify host names, domain names, or both in the DNS database. See the Solaris Naming Setup and Configuration Guide for more information about administering DNS.

  1. Become superuser.

  2. 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 shown below, for the DNS host aliases to be used.


    # grep hosts /etc/nsswitch.conf
    #hosts:      nisplus [NOTFOUND=return] files
    hosts:      nisplus dns [NOTFOUND=return] files
  3. Check for a mailhost and mailhost.domainname entry.

    Make sure an entry exists for mailhost and mailhost.domainname in the DNS database.

Building a sendmail Configuration File

The process to create sendmail configuration files has been changed. For many sites, This change should assist the administration of the configuration files. Although it is still acceptable to use an older version of sendmail.cf files, it would be best to move to the new system as soon as is reasonable. A complete description of the new process is described in /usr/lib/mail/README.

How to Build a New sendmail.cf File

  1. Become superuser.

  2. Make a copy of the configuration files that you want to change.


    # cd /usr/lib/mail/cf
    # cp main-v7sun.mc myhost.mc
    
  3. Edit the new configuration files as needed (for example myhost.mc).

  4. Build the configuration file using m4.


    # /usr/ccs/bin/make myhost.cf
    
  5. Test the new configuration file using the -C option to specify the new file.


    # /usr/lib/sendmail -C myhost.cf -v testaddr </dev/null
    

    This command sends a message to testaddr while displaying messages as it runs. 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 found in "How to Test the Mail Configuration".

  6. (Optional) 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
    
  7. Restart the sendmail service.


    # pkill -HUP sendmail
    

Administering Mail Alias Files

Mail aliases must be unique within the domain. This section tells you how to use command lines to search the mail aliases table for aliases, and to create mail aliases for NIS+, NIS, or on the local system. Or you can use the AdminTool's Database Manager application to perform these tasks on the aliases database.

In addition, database files can be created for the local mail host using makemap. Using these database files does not provide the all of the advantages of using a name space like NIS or NIS+, but retrieving the data should be faster than using local files.

How to List the Contents of an NIS+ Aliases Table

To use the aliasadm command, you must be either root, a member of the NIS+ group that owns the mail_aliases table, or the person who created the table.

Example--Listing All of the NIS+ mail_aliases Table

    Type aliasadm -l and press Return.

This lists the contents of the aliases table in alphabetical order by alias.


Note -

If you have a large aliases table, listing the entire contents can take some time. If you are searching for a specific entry, pipe the output through the grep command (aliasadm -l | grep entry) so that you can use the grep search capability to find specific entries.


Example--Listing Individual Entries in the NIS+ mail_aliases Table

    Type aliasadm -m alias and press Return.

The alias entry is listed.


# aliasadm -m ignatz
ignatz: ignatz@saturn # Alias for Iggy Ignatz

Note -

The aliasadm -m option matches only the complete alias name. It does not match partial strings. You cannot use metacharacters (like * and ?) with the aliasadm -m option. If you are interested in partial matches, type aliasadm -l | grep partial-string and press Return.


How to Add Aliases to a NIS+ mail_aliases Table From the Command Line

  1. Compile a list of each of your mail clients, the locations of their mailboxes, and the names of the mail server systems.

  2. Become root on any system.

  3. Optional: If necessary, initiate a NIS+ table

    If you are creating a completely new NIS+ mail_aliases table, you must first initiate the table. Type aliasadm -I and press Return.

  4. For each alias, type aliasadm -a alias expanded_alias [options comments] and press Return.

    This adds the aliases to the NIS+ aliases table.


    # aliasadm -a iggy iggy.ignatz@saturn "Iggy Ignatz"
  5. Type aliasadm -m alias and press Return.

    This displays the entry you created.

  6. Check that the entry is correct.

How to Add Entries by Editing a NIS+ mail_aliases Table

If you are adding more than two or three aliases, you might want to edit the NIS+ table directly.

  1. Compile a list of each of your mail clients, the locations of their mailboxes, and the names of the mail server systems.

  2. Become root on any system.

  3. Type aliasadm -e and press Return.

    The aliases table is displayed using the editor set with the $EDITOR environment variable. If the variable is not set, vi is the default editor.

  4. Type each alias on a separate line, using these formats:

    1. Type the aliases in any order, at any place in the table.

      The order is not important to the NIS+ mail_aliases table. The aliasadm -l command sorts the list and displays them in alphabetical order.

    2. Use the format alias: expanded_alias # ["option"# "comments"]

      If you leave the option column blank, type an empty pair of quotation marks ("") and then add the comments.

    3. End each line by pressing Return.

  5. Check that the entries are correct.

  6. Save the changes.

How to Change Entries in a NIS+ mail_aliases Table

  1. Become root on any system.

  2. Type aliasadm -m alias and press Return.

    The information for the alias is displayed.

  3. Type aliasadm -c alias expanded_alias [options comments] and press Return.

    The alias is changed using the new information you provide.

  4. Type aliasadm -m alias and press Return.

    The entry you created is displayed.

  5. Check that the entry is correct.

How to Delete Entries From a NIS+ mail_aliases Table

  1. Become root on any system.

  2. Type aliasadm -d alias and press Return.

    The alias is deleted from the NIS+ mail_aliases table.

How to Set Up NIS mail.aliases Map

  1. Compile a list of each of your mail clients, the locations of their mailboxes, and the names of the mail server systems.

  2. Become root on the NIS master server.

  3. Edit the /etc/mail/aliases file, and make the following entries:

    1. Add an entry for each mail client.

    2. Change the entry Postmaster: root to the mail address of the person who is designated as postmaster.

      See "How to Set Up the Postmaster Alias" for more information.

    3. If you have created a mailbox for administration of a mail server, create an entry for root:mailbox@mailserver.

    4. Save the changes.

  4. Edit the /etc/hosts file on the NIS master server and create an entry for each mail server.

  5. Type cd /var/yp and press Return.

  6. Type make and press Return.

    The changes in the /etc/hosts and /etc/mail/aliases files are propagated to NIS slave systems. It takes a few minutes, at most, for the aliases to take effect.

How to Set Up a Local Mail Alias File

  1. Compile a list of each of your mail clients and the locations of their mailboxes.

  2. Become root on the mail server.

  3. Edit the /etc/mail/aliases file and make the following entries:

    1. Add an entry for each mail client.

    2. Change the entry Postmaster: root to the mail address of the person who is designated as postmaster.

      See "How to Set Up the Postmaster Alias" for more information.

    3. If you have created a mailbox for administration of a mail server, create an entry for root: mailbox@mailserver.

    4. Save the changes.

  4. Type newaliases and press Return.

    This creates an alias file in binary form that sendmail can use. The file is stored in the /etc/mail/aliases.dir and /etc/mail/aliases.pag files.

  5. Copy the /etc/mail/aliases, the /etc/mail/aliases.dir, and /etc/mail/aliases.pag files to each of the other systems.

    When you copy all three files you do not need to run the newaliases command on each of the other systems.

    You can copy the files by using the rcp or rdist commands or by using a script that you create for this purpose. Remember that you must update all the /etc/mail/aliases files each time you add or remove a mail client.

How to Create a Keyed Map File

  1. Using the editor of your choice, create the input file.

    Entries can look like the following:


    sandy@newdomain.com     ssmith@newdomain.com
    ssmith@olddomain.com    error:nouser No such user here
    @olddomain.com          %1@newdomain.com

    In this sample, the first entry redirects mail to a new alias; the second entry creates a message when an incorrect alias is used; and the last entry redirects all incoming mail from olddomain to newdomain.

  2. Make the database file.


    # /usr/sbin/makemap -o dbm newmap < newmap
    

    -o

    Append to instead of overwriting the file. See makemap(1M) for a list of the options available.

    dbm

    Selects the dbm database type. Other map types are btree or hash.

    newmap

    Is 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 database files are created using a .pag and a .dir suffix. For the other two database types, the file name is followed by .db.

How to Set Up the Postmaster Alias

Every system should be able to send mail to a postmaster mailbox. You can create a NIS or NIS+ alias for postmaster or create one in each local /etc/mail/aliases file. Here is the default /etc/mail/aliases entry:


# Following alias is required by the mail protocol, RFC 822
# Set it to the address of a HUMAN who deals with this system's
# mail problems.
Postmaster: root

To create the postmaster alias, edit each system's /etc/mail/aliases file and change root to the mail address of the person who acts as postmaster.

You might want to 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 mail address when you edit the /etc/mail/aliases files.

How to Create a Separate Mailbox for postmaster

  1. Create a user account for the person designated as postmaster and put an asterisk (*) in the password field.

  2. After mail has been delivered, type mail -f postmaster and press Return.

    The mail program will be able to read and write to the mailbox name.

How to Add the postmaster Mailbox to the Aliases

  1. Become root and edit the /etc/mail/aliases file on each system.

    If your network does not run NIS or NIS+, edit the /etc/mail/aliases file.

  2. Change the postmaster alias from root to Postmaster: postmastermailbox@postmasterhost and save the changes.

  3. On the postmaster's local system create an entry in the /etc/mail/aliases file that defines the name of the alias (sysadmin, for example) and includes the path to the local mailbox.

  4. Type newaliases and press Return.

    Or you could change the Postmaster: entry in the aliases file to a Postmaster: /usr/somewhere/somefile entry.

Administering the Mail Queue

This section describes how to keep the mail service running smoothly.

How to Display the Mail Queue

You can print the contents of the queue with mailq.This command is equivalent to specifying the -bp flag to sendmail.

    Type /usr/bin/mailq | more and press Return.

A list of the queue IDs, the size of the message, the date the message entered the queue, the message status, and the sender and recipients are displayed.

How to Force Mail Queue Processing

    Type /usr/lib/sendmail -q -v and press Return.

This forces the processing of the queue and displays progress of the jobs as the queue is cleared.

How to Run a Subset of the Mail Queue

    Type /usr/lib/sendmail -qRstring and press Return.

You can run a subset of the queue at any time with the -qRstring (run queue where any recipient name matches string) or with -qInnnnn (run just one message with queue ID nnnnn). The string can also match host names, so any substring of user@host.domain will match.

This example processes everything in the queue for recipient wnj.


# /usr/lib/sendmail -qRwnj

How to Move the Mail Queue

  1. Become root on the mail host.

  2. Type /etc/init.d/sendmail stop and press Return.

    This kills the old sendmail daemon to keep it from trying to process the old queue directory.

  3. Type cd /var/spool and press Return.

  4. Type mv mqueue omqueue; mkdir mqueue and press Return.

    This moves the directory, mqueue, and all its contents to the omqueue directory and then creates a new empty Rmqueue directory.

  5. Type chmod 755 mqueue; chown daemon.daemon mqueue and press Return.

    These commands set the permissions of the directory to read/write/execute by owner, and read/execute by group and others; these commands also set the owner and group to daemon.

  6. Type /etc/init.d/sendmail start and press Return.

    This starts a new sendmail daemon.

How to Run the Old Mail Queue

  1. Type /usr/lib/sendmail -oQ/var/spool/omqueue -q and press Return.

    The -oQ flag specifies an alternate queue directory and the -q flag says to run every job in the queue. Use the -v flag if you want to see the verbose output displayed on the screen.

  2. When the queue is finally emptied type rmdir /var/spool/omqueue and press Return.

    This removes the empty directory.

Administering .forward Files

This section contains several procedures related to .forward file administration. Because these files can be edited by users, the files can cause problems.

How to Disable .forward Files

This procedure disables .forward files only for a particular host.

  1. Become root.

  2. 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
    
  3. Add the following line to the file you just created:


    define(`confFORWARD_PATH',`')dnl

    If a line already exists in the domain m4 file that you are using, replace the line.

  4. Build and install a new configuration file.

    See "How to Build a New sendmail.cf File" for a complete procedure.

How to Change the .forward File Search Path

  1. Become root.

  2. 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
    
  3. Add a line like the following to the file you just created:


    define(`confFORWARD_PATH',`~z/.forward:/var/forward/$u')dnl

    If a line already exists in the domain m4 file that you are using, replace the line.

  4. Build and install a new configuration file.

    See "How to Build a New sendmail.cf File" for a complete procedure.

How to Create and Populate /etc/shells

This file is not included in the standard release, so it must be added 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 by hand by using grep to identify all of the shells listed in your password file, then enter them manually in the file, but it is easier to use the following procedure, which employs a script that can be downloaded.

  1. Download the script from http://www.sendmail.org/sun-specific/gen-etc-shells.html.

  2. Become root.

  3. 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 included in the password file sources listed in /etc/nsswitch.conf.

  4. Inspect the list of shells in /tmp/shells.

    Using the editor of your choice, remove any shells that you do not want included.

  5. Move the file to /etc/shells.


    # mv /tmp/shells /etc/shells
    

Troubleshooting Tips for Mail

This section provides some tips and tools that you can use for troubleshooting problems with the mail services.

How to Test the Mail Configuration

  1. Restart sendmail on any system for which you have changed a configuration file.


    # pkill -HUP sendmail
    
  2. Send test messages from each system by typing /usr/lib/sendmail -v names </dev/null and press Return.

    Specify a recipient's email address in place of the names variable.

    This command sends a null message to the specified recipient and displays messages while it runs.

  3. Run these tests:

    1. Send mail to yourself or other people on the local system by addressing the message to a regular user name.

    2. If you are on Ethernet, send mail to someone on another system.

      Do this in three directions: from the main system to a client system, from a client system to the main system, and from a client system to another client system.

    3. If you have a mail gateway, send mail to another domain from the mail host to ensure that the relay mailer and host are configured properly.

    4. If you have set up a UUCP connection on your phone line to another host, send mail to someone at that host and have that person send mail back or call you when the message is received.

    5. Ask someone to send mail to you over the UUCP connection.

      The sendmail program cannot tell whether the message gets through because it hands the message to UUCP for delivery.

    6. Send a message to postmaster on different systems and make sure that it comes to your postmaster's mailbox.

How to Check Mail Aliases

To verify aliases and whether mail can be delivered to a given recipient:

    Type /usr/lib/sendmail -v -bv recipient and press Return.

The command displays the aliases and identifies the final address as deliverable or not.

Here is an example of the output:


% /usr/lib/sendmail -v -bv sandy
sandy... aliased to   ssmith
ssmith... aliased to              sandy@phoenix
sandy@phoenix... deliverable: mailer esmtp, host phoenix, user sandy@phoenix.eng.acme.com
%

You should take extra care to avoid loops and inconsistent databases when both local and domain-wide aliases are used. Be especially careful when you move a user from one system to another to avoid creating alias loops.

How to Test the sendmail Rule Sets

  1. Type /usr/lib/sendmail -bt and press Return.

    Information is displayed.

  2. At the last prompt (>) type a 3,0 (zero) and the mail address you want to test.

  3. Type Control-d to end the session.

Here 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
rewrite: ruleset   3   input: sandy @ phoenix
rewrite: ruleset  96   input: sandy < @ phoenix>
rewrite: ruleset  96 returns: sandy < @ phoenix . eng . acme . com . >
rewrite: ruleset   3 returns: sandy < @ phoenix . eng . acme . com . >
rewrite: ruleset   0   input: sandy < @ phoenix . eng . acme . com . >
rewrite: ruleset 199   input: sandy < @ phoenix . eng . acme . com . >
rewrite: ruleset 199 returns: sandy < @ phoenix . eng . acme . com . >
rewrite: ruleset  98   input: sandy < @ phoenix . eng . acme . com . >
rewrite: ruleset  98 returns: sandy < @ phoenix . eng . acme . com . >
rewrite: ruleset 198   input: sandy < @ phoenix . eng . acme . com . >
rewrite: ruleset 198 returns: $# local $: sandy
rewrite: ruleset   0 returns: $# local $: sandy

How to Verify Connections to Other Systems

To verify connections to other systems, you can use the mconnect program to open connections to other sendmail systems over the network. The mconnect program runs interactively. 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 shamira is deliverable.


$ mconnect phoenix
connecting to host phoenix (129.144.52.96), port 25
connection open
220 phoenix.Eng.Acme.COM Sendmail 8.9.0+Sun/8.9.0; Tue, 25 Jul 1998 10:45:28 -0700
vrfy sandy
250 Sandy Smith <sandy@phoenix.Eng.Acme.COM>
>

If you cannot use mconnect to connect to an SMTP port, check these conditions:

System Log

The mail services log most errors using the syslogd program. The default is for syslogd to send messages to the loghost.

You can define a system called loghost in the /etc/hosts file to hold all logs for an entire NIS domain. The system log is supported by the syslogd program. You specify a loghost in /etc/hosts. If no loghost is specified, error messages from syslogd are not reported.

Example 34-1 shows the default /etc/syslog.conf file.


Example 34-1 Default /etc/syslog.conf File


#ident "@(#)syslog.conf   1.3        93/12/09 SMI"  /* SunOS 5.0 */  #
# Copyright (c) 1994 by Sun Microsystems, Inc. 
#
# syslog configuration file. 
# 
# This file is processed by m4 so be careful to quote (`') names 
# that match m4 reserved words. Also, within ifdef's, arguments 
# containing commas must be quoted. 
# 
# Note: Have to exclude user from most lines so that user.alert 
#       and user.emerg are not included, because old sendmails 
#       have no 4.2BSD based systems doing network logging, you 
#       can remove all the special cases for "user" logging.
# *.err;kern.debug;auth.notice;user.none	        /dev/console 
*.err;kern.debug;daemon,auth.notice;mail.crit;user.none /var/adm/messages 
*.alert;kern.err;daemon.err;user.none            operator 
*.alert;user.none	                               root 
*.emerg;user.none	                               * 
# if a non-loghost machine chooses to have authentication messages 
# sent to the loghost machine, un-comment out the following line:
#auth.notice         ifdef(`LOGHOST', /var/log/authlog, @loghost) 
mail.debug           ifdef(`LOGHOST', /var/log/syslog, @loghost) 
# 
# non-loghost machines will use the following lines to cause "user" 
# log messages to be logged locally. 
# 
ifdef(`LOGHOST', , 
user.err             /dev/console 
user.err             /var/adm/messages 
user.alert           `root, operator' 
user.emerg           * 
)

You can change the default configuration by editing the /etc/syslog.conf file. You must restart the syslog daemon for any changes to take effect. You can add these selections to the file to gather information about mail:

The following entry 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 it, and a message. The syslog file can log a large amount of information.

The log is arranged as 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 higher than 10 are usually used for debugging. See the "mconnect" in System Administration Guide, Volume 2 for information about loghost and the syslogd program.

Other Mail Diagnostic Information

For other diagnostic information, check the following sources: