The smail mail system is similar to the sendmail system in most of its actions, although the configuration process is different. In some ways, smail is easier to work with than sendmail, and it can be a good choice for smaller systems. If you choose to use smail as your mailer, you will have to make some manual modifications to configuration files because there are few automated or scripted routines available.
The smail system has many options and configuration details, most of which are never used. This chapter looks at the primary controlling parameters that most Linux users may need and essentially ignores those that are very seldom (if ever) used in real situations. For more information on the options and configuration controls not covered in this chapter, see the man pages or smail documentation. Essentially, this chapter shows you how to get smail up and running quickly to handle the situations most Linux systems will find themselves working with.
The smail system is governed by a daemon that is usually started when the system enters multiuser run mode. From then on, smail watches for incoming connections (TCP or UUCP, usually), and it processes any incoming mail when it is received. Because smail runs as a daemon, this allows fast processing and delivery of incoming mail without having to physically start a mail program at intervals. When mail is received through a UUCP connection, the rmail program is often called to handle the delivery of the mail.
The smail system was designed to process incoming mail immediately, routing it to the receiver. You can override this in the main configuration file, usually called /usr/lib/smail/config, which may be necessary in high-traffic situations or when a machine is heavily loaded. When desired, the inetd daemon can handle incoming mail traffic and spawn smail to handle the delivery at specific intervals. However, using smail as a daemon generally involves less overhead and system resources than spawning it every time mail has to be handled, so the daemon approach is recommended.
The smail system handles outgoing mail through the use of a connection to a user's mailer. For example, if you send a message from one of the Linux mailer agents such as Elm or mail, that application sends the mail and recipient names to the rmail (usually /usr/bin/rmail) program for delivery. Some mail agents send outgoing mail to the sendmail program instead of rmail, which also has to be accounted for. As you will see in the next section, both incoming and outgoing mail is usually handled by creating links between smail, rmail, and sendmail.
The smail mail-handling routine is broken into three distinct and separate parts: the router, the director, and the transport. The router handles address resolution and the way in which messages are sent between machines. The director handles forwarding and aliases that may be used in messages. The transport handles the actual transfer of messages. Each of the three components can be configured separately within smail using separate files called routers, directors, and transports (which usually reside in the /usr/lib/smail directory with the smail configuration files). You will look at modifying the default behavior of each component later in this chapter.
Most Linux systems have the smail program reside in the directory /usr/local/bin, although a few other locations are popular as well. You need to know the exact directory path to smail in order to properly configure the system, so find the executable. You can locate its path with the following command:
find / -name smail -print
The smail system requires several links to exist so smail can execute properly. The two most important links are to the files /usr/bin/rmail and /usr/lib/sendmail (sometimes located as /usr/sbin/sendmail, depending on the version of Linux). These links are necessary because most user mail applications send outgoing mail to either rmail or sendmail (depending on the mail software), and this has to be redirected to smail. Links allow this redirection to occur transparently without altering the user mail applications.
Verify that the rmail and sendmail files are linked to smail, and if not, establish the links. Usually, the links established are symbolic, and they will show in a directory listing with an entry like this:
lrwxrwxrwx 1 root root 6 Sep 16:35 file1 -> file2
The arrow (->) shows that a symbolic link exists. (For more information on links and symbolic links, see Chapter 18, "Filesystems and Disks.") Check both the rmail and sendmail binaries for these symbolic links. If the symbolic links do not exist already, create them with the following commands:
ln -s /usr/local/bin/smail /usr/bin/rmail ln -s /usr/local/bin/smail /usr/lib/sendmail
Of course, you should substitute whatever directory pathnames are valid on your system for smail, sendmail, and rmail. Once you have created the links, verify that they exist by displaying the directories and look for the symbolic link notation shown earlier.
If mail may enter or leave your system through an SMTP channel, you should also establish a link between the smail program and the smtp system. Use the following command to set up the link (substituting proper paths for your system):
ln -s /usr/local/bin/smail /usr/sbin/smtpd
Next, the SMTP service has to be enabled through the TCP configuration files. You do this by setting the /etc/services file to specifically enable SMTP connections. There is a line in the /etc/services file that looks like this:
smtp 25/tcp # Simple Mail Transfer Protocol
Verify that this line is not commented out (has a pound sign as the first character). This line allows the SMTP link to be established as TCP port number 25 (the default value).
If you are going to leave smail as a daemon (started automatically with the system boot), ensure that the smail daemon is started in the rc files (such as rc.inet2). The usual command line for the smail daemon looks like this:
/usr/local/bin/smail -bd -q15m
The -bd option turns the daemon operation of smail on, and the -q15m tells smail to process messages every 15 minutes. If you want more frequent mail delivery, change the value in the rc file. Alternatively, if you want mail processing less often to relieve a heavily loaded system, increase the value.
If you decide not to run smail as a daemon and want it spawned by inetd whenever mail arrives, comment out the daemon lines in the rc files (usually rc.inet2). You cannot run smail in both daemon and spawned mode. Next, modify the /etc/inetd.conf file to contain an entry like the following:
smtp stream tcp nowait root /usr/sbin/smtpd smtpd
You must have the symbolic link between smtpd and the smail program for this command to function properly.
The configuration file changes necessary for smail depend on which connection system you use for obtaining mail. In other words, the configurations change if you are using UUCP (which is the easiest to set up) or a TCP connection on a network. This chapter looks at each of the configuration processes separately. You can follow both discussions, if you enable mail through both methods.
Configuring the smail system for use with UUCP incoming and outgoing mail messages is very simple. You need to edit the default smail configuration file, usually stored as /usr/lib/smail/config. Some versions of smail include a sample configuration file as config.sample in the same directory. You can use either as a template for the UUCP modifications.
Use any ASCII editor to edit /usr/lib/smail/config. You need to make four changes. The changes are for these variables:
| visible_domain | The domain names your site belongs to |
| visible_name | Your site's full domain name |
| uucp_name | Your site's UUCP-based name (usually the same as visible_name) |
| smart_host | The name of the UUCP host |
Each parameter in the /usr/lib/smail/config file uses the same format of variable=value. There should be no spaces on either side of the equal sign on any line. A pound sign precedes comments in the file.
Begin by setting the domain name of the local machines. Locate the line in the /usr/lib/smail/config file that defines the variable visible_domain, which will usually look similar to this:
# Our domain name visible_domain=tpci
The visible_domain variable sets the domain names your site belongs to, and it will usually be the fully qualified domain name and any aliases that may be in effect. This field is used by smail to find out if the recipient of a message is local or not. The smail system takes the message and extracts the recipient's address, comparing it against the local machine name (from the hostname command) and all values specified on the visible_domain variable. If there is a match to any of these names, the message is for a local recipient. If no match occurs, the message is routed externally.
If there is more than one valid value for a local domain name, the values are separated by colons, as shown in this example:
visible_domain=tpci:tpci.com:tpci.UUCP
If your site is properly registered on UUCP maps, add the domain uucp to the list of valid values, as well. In this example, you belong to the domain tpci (from the full domain name tpci.com), and uucp:
visible_domain=tpci:tpci.com:uucp
When a message is to be routed out of the local machine, the smail system appends the local machine's full domain name as part of the routing information. The full local machine name is defined in the /usr/lib/smail/config line that deals with the visible_domain variable. The line looks something like this:
# Our domain name for outgoing mail visible_name=tpci.com
As a general rule, the visible_domain value must be a combination of the hostname and one of the domains given in the visible_domains variable. Otherwise, the smail system may bounce incoming mail issued as a reply to mail sent from your site as being unrecognizable.
The visible_name value is usually your fully qualified domain name (if you have one) or a domain name that exists in other routing tables.
The /usr/lib/smail/config file sometimes contains an entry for a variable called uucp_name. This variable is usually optional, as long as the variables visible_domain and visible_name are properly filled in. The uucp_name variable is used when the name of the system returned by the hostname command is not the name that is registered with the UUCP mapping tables. For example, your UUCP mapping name may be darkstar, but you may have changed your machine's name to vader for any number of reasons. You can use the uucp_name variable to correct this change, without requiring updates to the UUCP mapping tables.
To set a value for the uucp_name variable, look for (or create, if one doesn't exist) the lines that define the variable. Usually, the lines look like this:
# UUCP mapping name uucp_name=tpci.com
If your name is properly registered as set in the visible_name variable, you can simply repeat the value in the uucp_name variable with no ill effects. If your site name has changed, enter the proper value instead.
Some systems use another machine as a smart host that handles the routing of messages to and from other networks. If you are using a smart host, you should put its name in the /usr/lib/smail/config file next to the variable smart_host. Look for entries in the file that resemble these lines:
# Smart host smart_host=merlin
In this case, any mail for other networks is forwarded by smail to the machine merlin (in the fully resolved domain name merlin.tpci.com, based on the smart_host and visible_name variables). That machine can then take care of the routing out of the network. Any machine name given in the smart_host field must be reachable by UUCP, which means having a corresponding UUCP configuration entry. (See Chapter 27, "UUCP," for more information.)
If you are going to use a network connection to transfer mail, you need to make modifications to the /usr/lib/smail/config file that specify the types of connections and host names. There are several different methods of configuring mail systems for a network. These methods include using NFS (Network File System) to allow a single configuration file shared by all machines, using POP (Post Office Protocol) or IMAP (Interactive Mail Access Protocol) to handle mail on a central site, and setting up each machine as an independent mail handler. The configuration process for all these methods is much the same. The difference is whether the configuration files reside on each machine in the network, or on a single machine that is then accessed by NFS or SMTP by other machines.
Start the configuration process by establishing the local domain names using the variables visible_domain and visible_name. These variables were discussed in detail in the section on configuring smail for UUCP., so the explanation will be limited to showing final examples of these two variables. An example of these variable definitions looks like this:
# Our domain name visible_domain=tpci.com # Our domain name for outgoing mail visible_name=tpci.com
This code sets the local domain name and domain resolution names. The entry for visible_domain is used by smail to attach to all outgoing mail packages (instead of whatever name is generated by the hostname command). Both visible_domain and visible_name are often the same.
The next configuration step is to set the name of a smart host that handles out-of-network messages. If you are not using a smart host, or your machine handles the network connections itself, you won't need to enter these values. The variables involved in setting up a smart host are smart_path and smart_transport. The smart_path sets the machine name of the smart host (which must be resolvable with the domain name given in visible_domain). The smart_transport variable specifies the type of protocol to be used to connect to the smart host. Because most smart hosts communicate (for mail purposes, at least), with SMTP, that is the most often used value, as shown in this extract from a /usr/lib/smail/config file:
# smart host routing # smart host name smart_host=merlin # communications protocol to smart host smart_transport=smtp
The smart_transport value of smtp (lowercase letters only) is used to identify the SMTP connection protocol.
As mentioned at the start of this chapter, smail can use many configuration options and command line options, although most are of little interest to most Linux system users. A few of the options may be of interest if you want to modify the basic behavior of smail. This section examines these options.
Both UUCP and TCP-based smail systems can add an entry to the /usr/lib/smail/config file that prevents misrouted mail from bouncing around the network until it dies from excess hops. This is controlled by the auth_domains variable, which is used by smail to validate any incoming mail package. When smail receives a message for the local network machine, it checks to see whether the local machine's name is known. If not, the message is returned to the sender.
To set an authoritative name validation in the /usr/lib/smail/config file, check for (or add) these lines:
# auth domain name auth_domains=tpci.com
This code limits the mail messages bouncing around the local network to any valid host name in the domain tpci.com. If the name is not recognized in the local network, it doesn't get circulated. This sometimes can help prevent congestion on a network when large files are misrouted.
You can set the smail system to process incoming mail in different ways (other than the daemon or spawned process startup options discussed earlier). You can set smail to store incoming and outgoing messages in a queue and process them at later times, or to process mail immediately. This process is controlled with the queue_only and delivery_mode variables.
The queue_only variable is a Boolean value that, if set, enables the delivery_mode variable, which can be set to one of three values:
| foreground | Processes incoming messages immediately |
| background | The message is delivered by a child process |
| queued | Holds the message for later processing |
When queuing is enabled, messages are held in a smail queue (usually in /var/spool/smail/messages) until the queue is processed. The processing is controlled by the -q option on the smail command line (if smail is started as a daemon), or by issuing the command runq from a crontab file (if smail is run from inetd). (For the latter to work properly, runq must be linked to smail).
Recall the startup command line from the rc file shown earlier:
/usr/local/bin/smail -bd -q15m
You remember that the queue is processed every 15 minutes in this example. The queue process command can be set to any value, but it should not be left for too long as the queue files can get very large.
You can display the current contents of the smail queue by issuing the smail command with the -bp option or with the command mailq, which should be linked to smail.
Every network should have a postmaster, which is a user who receives all the status messages from the mail systems as well as queries from other networks about the local area network and its users. By default, the postmaster ID is set to root, although you can override it with the command like this in the /usr/lib/smail/config file:
postmaster=tparker
This command routes all messages for the postmaster to the user tparker. You only need to specify this option in the /usr/lib/smail/config file if you want to change the default setting of root.
You can configure the postmaster to receive all error messages that are generated because of configuration errors. Add the Boolean variable to the /usr/lib/smail/config file:
+error_copy_postmaster
If this entry doesn't exist with a plus sign ahead of it, messages are not copied to the postmaster.
In normal operation, smail uses two log files to record actions. Most transactions are recorded in the file /var/spool/smail/log/logfile (your path may differ, depending on the version of Linux). Each entry in the log reflects a complete smail transaction and includes the identification number of the message, sender, recipient, times, size, and routing information. You can use the contents of the log file to check for proper behavior of the smail system.
Errors and other problems are recorded in the file paniclog (usually /var/spool/smail/log/paniclog). An entry in this file tends to show the basic information about a message as well as the reason the message couldn't be sent. For example, the most common error is a failure to route a message through SMTP, which produces the log summary:
(ERR_148) transport smtp: connect: Connection refused
If you see these error messages in the paniclog file, it usually means SMTP has failed, the connection is not responding because the remote host is down, or the TCP service is not enabled (check /etc/services).
If the entries in the paniclog file don't help you isolate a problem, you can enable a debugging mode on smail by adding the option -d followed by a number to the startup command. The number reflects the amount of debugging information to be generated and displayed on the screen. It is best to kill the smail daemon (if one is being used) and restart it at a shell prompt with this option active, instead of embedding the debug option in the rc file.
If you are not getting any mail forwarded to your mailbox, check the pathnames of the mailbox files. Usually, mailboxes are stored in /usr/spool/mail/username where username is each user's mailbox. Some versions of Linux use /var/spool/mail instead, and some mail applications may be expecting a specific address for the mailbox. If you are not sure whether the mailbox location is correct, try creating links between /usr/spool/mail/username and /var/spool/mail/username.
The configuration files and processes mentioned earlier apply for most Linux systems, and many systems will require no further actions than those already covered. However, as mentioned earlier in this chapter, smail's three components (router, director, and transport) can each be further configured to modify their behavior. This capabilty can help you fine-tune or modify your smail installation to meet particular network needs. The only component you really need to examine in detail is the router, as the director and transport seldom need customization for a typical Linux installation.
In most cases, the behavior of each smail component is handled by a file (or several files) based in the smail configuration directory (usually /usr/lib/smail). Many sample configuration files are available from Linux distribution CD-ROMs and FTP sites that show different configurations. Obtaining one of these sample files, and then modifying it for your host-specific details, is easier than building the files from scratch. The number of options and details change with the release of smail, so check to see whether you have a complete version.
The router component of smail handles the resolution of destination addresses, routing to the next mail host for further forwarding, and determination of which transport should be used to send the message on. The router component performs a number of tasks, first determining if the message is for a local or remote machine (using the variable values defined in /usr/lib/smail/config). If the message is for a local machine, the message is handed off to the director.
If the message is for a remote machine, the message's address is given to router drivers to determine which host the message should be forwarded to. The router drivers are specified in the file routers (usually /usr/lib/smail/routers). The file contains the names of the router drivers, each of which (in the order presented in the routers file) is given the message destination address to see if they have information about the specific route required to send the message.
You don't need to specify any other routers than the default configuration in most cases. The default setup uses the following router steps, in order:
These default routings work for most systems, although you should comment out the UUCP router if your system is not properly configured to handle UUCP. Otherwise, you will get tons of error messages. If you do not plan to use UUCP for mail, you should also comment out this router line to simplify the entire smail system.
A couple of other common situations need to be dealt with. If you are connected to the Internet, there is a problem in that smail's router doesn't recognize the MX record format. In order to properly support Internet mail, comment out the default router and enable the BIND router instead. (If your version of Linux doesn't support BIND, you can obtain and link a more recent version from FTP and BBS sites.)
If you are using both SLIP/PPP and UUCP connections, you may encounter problems with smail waiting too long for a connection. To simplify this type of installation, rearrange the order the routers are checked so that the paths file is checked before the resolver router. In many cases, because UUCP is more efficient and faster than SMTP over a SLIP/PPP line, you can disable the resolver-based router entirely.
When a router identifies the best route to the destination machine, it also gives the transport required to communicate with that machine's mail router. The actual path to the destination may be modified at this point. For example, if the remote machine chatton@bigcat.com can best be reached through a UUCP link instead of SMTP, the destination address may be modified by the router to bigcat!chatton (UUCP-style addressing). Alternatively, a destination address may become more specific. For example, the address chatton@bigcat.com may be resolved to a specific machine such as chatton@whiskers.bigcat.com, if that address will get the message delivered more efficiently.
Some UUCP routers use the /usr/lib/smail/paths file is used by to determine a path alias. The paths file is ASCII only and contains a sorted list of entries with two columns separated by a tab: the destination site name and its UUCP bang path. No comments are allowed in the file.
This chapter has looked at the configuration of the smail mail system for UUCP and TCP-based mail connections. In either case, the configuration process is usually a matter of modifying a single file, unless you have several different connections to the outside world. It is the simplicity of configuration that makes smail popular with Linux users.
