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.
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.
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.
To set up this kind of mail configuration, you need:
The default /etc/mail/sendmail.cf file on each mail client system (no editing required)
A server designated as the mail host (add mailhost.domainname 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)
Matching /etc/mail/aliases files on any system that has a local mailbox (unless you are running NIS or NIS+)
Enough space in /var/mail on each mail client system to hold the mailboxes
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:
The default /etc/mail/sendmail.cf file on each mail client system (no editing required)
A server designated as the mail host (add mailhost.domainname 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)
Matching /etc/mail/aliases files on any system that has a local mailbox (unless you are running NIS or NIS+)
Entries in each mail client's /etc/vfstab file or /etc/auto_direct (if autofs is used) to mount the /var/mail directory
Enough space in /var/mail on the mail server to hold the client mailboxes
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.
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:
The main.cf file on the mail gateway (no editing required if MX records are used)
The default /etc/mail/sendmail.cf file on each mail client system (no editing required)
A server designated as the mail host (add mailhost.domainname to the /etc/hosts file on the mail host; if you are not running NIS or NIS+, add the mail host IP address line to the /etc/hosts file of all mail clients)
Matching /etc/mail/aliases files on any system that has a local mailbox (unless you are running NIS or NIS+)
Entries in each mail client's /etc/vfstab file or /etc/auto_direct (if autofs is used) to mount the /var/mail directory when mailboxes are located on the mail host
Enough space in /var/mail on the mail server to hold the client mailboxes
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.
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:
Complex gateway systems requiring a customized sendmail.cf file with special rules added
The main.cf file on the mail gateway (no editing required if you use MX records)
A server designated as the mail host (add mailhost.domainname to the /etc/hosts file on the mail host; if you are not running NIS or NIS+, add the mail host IP address line to the /etc/hosts file of all mail clients)
Matching /etc/mail/aliases files on any system that has a local mailbox (unless you are running NIS or NIS+)
An alias entry for each user, to point to where the mail is stored, in mail_aliases.org_dir for NIS+ or the aliases map for NIS
The default /etc/mail/sendmail.cf file on each mail client system (no editing required)
Entries in each mail client's /etc/vfstab file or /etc/auto_direct (if autofs is used) to mount the /var/mail directory when mailboxes are located on the mail host
Enough space in /var/mail on the mail server to hold the client mailboxes
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.
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.
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.
Become superuser on the mail server.
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.
Make the /var/mail directory available for remote access.
Type the following command:
# share -F nfs /var/mail |
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 |
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, and a mail alias in the /etc/mail/aliases file that points to the location of the mailbox.
Become superuser on the mail client's system.
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.
Mount the /var/mail directory from the mail server.
The mail directory can be automatically mounted or mounted at boot time.
(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 |
(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.
You must include the actimeo=0 option when mounting mail from an NFS server to allow mailbox locking and access to work properly.
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.
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.
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.
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.
Become superuser on the mail host system.
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.
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 |
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
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 |
Restart sendmail and test your mail configuration.
See "How to Test the Mail Configuration" for information.
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.
Become superuser on the mail gateway.
Change the configuration file.
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 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.
Restart sendmail and test your mail configuration.
See "How to Test the Mail Configuration" for information.
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.
Become superuser.
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 |
Check for a mailhost and mailhost.domainname entry.
Make sure an entry exists for mailhost and mailhost.domainname in the DNS database.
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.
Become superuser.
Make a copy of the configuration files that you want to change.
# cd /usr/lib/mail/cf # cp main-v7sun.mc myhost.mc |
Edit the new configuration files as needed (for example myhost.mc).
Build the configuration file using m4.
# /usr/ccs/bin/make myhost.cf |
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".
(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 |
# pkill -HUP sendmail |
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.
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.
Type aliasadm -l and press Return.
This lists the contents of the aliases table in alphabetical order by alias.
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.
Type aliasadm -m alias and press Return.
The alias entry is listed.
# aliasadm -m ignatz ignatz: ignatz@saturn # Alias for Iggy Ignatz |
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.
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 any system.
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.
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" |
Type aliasadm -m alias and press Return.
This displays the entry you created.
If you are adding more than two or three aliases, you might want to edit the NIS+ table directly.
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 any system.
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.
Type each alias on a separate line, using these formats:
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.
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.
End each line by pressing Return.
Check that the entries are correct.
Save the changes.
Become root on any system.
Type aliasadm -m alias and press Return.
The information for the alias is displayed.
Type aliasadm -c alias expanded_alias [options comments] and press Return.
The alias is changed using the new information you provide.
Type aliasadm -m alias and press Return.
The entry you created is displayed.
Check that the entry is correct.
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.
Edit the /etc/mail/aliases file, and make the following entries:
Add an entry for each mail client.
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.
If you have created a mailbox for administration of a mail server, create an entry for root:mailbox@mailserver.
Save the changes.
Edit the /etc/hosts file on the NIS master server and create an entry for each mail server.
Type cd /var/yp and press Return.
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.
Compile a list of each of your mail clients and the locations of their mailboxes.
Become root on the mail server.
Edit the /etc/mail/aliases file and make the following entries:
Add an entry for each mail client.
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.
If you have created a mailbox for administration of a mail server, create an entry for root: mailbox@mailserver.
Save the changes.
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.
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.
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.
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. |
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.
Create a user account for the person designated as postmaster and put an asterisk (*) in the password field.
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.
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.
Change the postmaster alias from root to Postmaster: postmastermailbox@postmasterhost and save the changes.
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.
Type newaliases and press Return.
Or you could change the Postmaster: entry in the aliases file to a Postmaster: /usr/somewhere/somefile entry.
This section describes how to keep the mail service running smoothly.
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.
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.
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 |
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.
Type cd /var/spool and press Return.
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.
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.
Type /etc/init.d/sendmail start and press Return.
This starts a new sendmail daemon.
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.
When the queue is finally emptied type rmdir /var/spool/omqueue and press Return.
This removes the empty directory.
This section contains several procedures related to .forward file administration. Because these files can be edited by users, the files can cause problems.
This procedure disables .forward files only for a particular host.
Become root.
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 |
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.
Build and install a new configuration file.
See "How to Build a New sendmail.cf File" for a complete procedure.
Become root.
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 |
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.
Build and install a new configuration file.
See "How to Build a New sendmail.cf File" for a complete procedure.
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.
Download the script from http://www.sendmail.org/sun-specific/gen-etc-shells.html.
Become root.
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.
Inspect the list of shells in /tmp/shells.
Using the editor of your choice, remove any shells that you do not want included.
Move the file to /etc/shells.
# mv /tmp/shells /etc/shells |
This section provides some tips and tools that you can use for troubleshooting problems with the mail services.
Restart sendmail on any system for which you have changed a configuration file.
# pkill -HUP sendmail |
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.
Run these tests:
Send mail to yourself or other people on the local system by addressing the message to a regular user name.
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.
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.
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.
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.
Send a message to postmaster on different systems and make sure that it comes to your postmaster's mailbox.
To verify aliases and whether mail can be delivered to a given recipient:
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.
Type /usr/lib/sendmail -bt and press Return.
Information is displayed.
At the last prompt (>) type a 3,0 (zero) and the mail address you want to test.
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 |
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:
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?
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.
#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:
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
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.
For other diagnostic information, check the following sources:
Look at the Received lines in the header of the message. These lines trace the route the message took as it was relayed. Iin the UUCP network many sites do not update these lines, and in the Internet the lines are rearranged. To straighten them out, look at the date and time in each line. Remember to account for time-zone differences.
Look at the messages from MAILER-DAEMON. These typically report delivery problems.
Check the system log that records delivery problems for your group of systems. The sendmail program always records what it is doing in the system log. You might want to modify the crontab file to run a shell script nightly that searches the log for SYSERR messages and mails any that it finds to the postmaster.
Use the mailstats program to test mail types and determine the number of incoming and outgoing messages.