COHERENT manpages

This page displays the COHERENT manpage for smail [Mail delivery system].

List of available manpages
Index


smail -- Command

Mail delivery system
smail [ flags ] address ...

smail is the program that receives and delivers mail.  It accepts mail from
a source either  on your local host or on  a remote host, and delivers that
mail to  its destination  -- again,  either on your  local host  or another
remote host.   smail does not provide  a user interface for  typing mail or
reading it;  to do so, you  must use a ``mailer'' program,  such as mail or
elm.

You will  rarely, if ever, need  to invoke smail directly.   You may modify
one of  its configuration files  from time to  time, but smail  normally is
invoked only  by other  programs.  The rest  of this article  gives smail's
command-line  options  and describes  how  it works.   You  will find  this
information  useful should  you wish  to reconfigure  your mail  system, or
chase down a bug.

smail can  be invoked under  a variety of  names.  Each name  indicates the
major use to which smail will be put, e.g., receiving local mail, receiving
remote  mail,  attempting   to  deliver  undelivered  mail,  or  displaying
information about undelivered  mail.  These names are described below; each
also has its own Lexicon entry.

Command-line Options

smail recognizes the following command-line options:

-bc  Display the  contents of file  COPYING, which is  distributed with the
     source  code  for  smail.  This  file  details what  your  rights  and
     restrictions the authors of smail have set upon their work.

-bd  Listen  for connection  requests  on a  socket bound  in the  Internet
     domain.   When a  connection occurs, conduct  an Simple  Mail Transfer
     Protocol  (SMTP)  conversation  with the  peer  process  on the  other
     system.  This  option currently is not  implemented under COHERENT, as
     COHERENT does not yet support networking.

-bi  Initialize the  aliases file.   The file  that it builds  depends upon
     whether you also use option -oA on the command line.

     By default,  smail under COHERENT  is compiled with  the GDBM package.
     GDBM is a  set of functions that permit a  program to build and read a
     simple hashed data base; for details  on how it works, see the Lexicon
     entry for libgdbm.  Thus, when you also use option  -oAfile to name an
     aliases  file, smail invokes  the command  /usr/lib/mail/newaliases to
     compile the contents of file into a DBM data base.

-bm address ...
     Deliver mail to each address.

-bP address
     Assume that  each address on the command  line is a configuration-file
     variable, and write its  value onto the standard output.  For example,
     the command

         smail -bP hostnames max_message_size

     produces output of the form:

         lepanto.com
         102400

     If you  also use the  flags -d or  -v on the command  line, smail also
     displays the variable names.  Thus, the command

         smail -bP -v max_message_size

     prints something like the following:

         max_message_size=102400

     The command

         smail -bP primary_name

     prints the  primary (or  ``canonical'') name  for the local  host that
     smail uses, and command

         smail -bP config_file

     prints the name of the primary configuration file.  The command

         smail -bP help

     prints a verbose listing of every variable plus its type, one variable
     per line.  Finally, command

         smail -bP all

     prints  a verbose  listing of  every  variable and  its value.   It is
     equivalent to the command smail -bP  -v followed by a list of the name
     of every configuration variable.

-bp  List information  about the messages that  currently reside in smail's
     input spool  directories.  This is  smail's  default mode of operation
     when you invoke it under the name mailq. When you also use the flags -
     v or -d, smail  displays the transaction-log entries for each message,
     to show what has happened to the message so far.

-bS  Read  SMTP commands  from the  standard input, but  do not  write SMTP
     replies  onto the  standard output.  Report  failures via  mail rather
     than through reply codes.

     This option is suitable for setting  up a batched form of SMTP between
     machines  over a  remote  execution service  like UUCP.   This is  the
     default mode of operation if you invoke smail under the name rsmtp.

-bs  Read SMTP  commands from standard  input, and write  SMTP replies onto
     the standard output.  The following SMTP commands are implemented:

          HELO      MAIL      FROM      RCPT
          TO        DATA      RSET      NOOP
          VRFY      EXPN      QUIT

     This is  the default mode of  operation if you invoke  smail under the
     name smtpd.

-bt  Run smail  in test-address mode:  smail reads addresses  from standard
     input, parses  them, and writes  its result onto  the standard output.
     This is  primarily useful for  debugging smail or  debugging new smail
     routers.

-bV  See option -V, below.

-bv  Verify an  address.  smail reads each address you  list on its command
     line, subjects it to aliasing and forwarding expansions, then subjects
     it  to host  routing  or resolving,  and finally  prints the  resolved
     address  onto the  standard output.   You can  then check  whether the
     resolved address matches what  you expect.  If smail cannot resolve an
     address, it prints an explanation of why it cannot.

-C file
     Use  file as  the primary  configuration file --  i.e., the  file that
     holds global  attributes.  smail resets the  effective user identifier
     and group  identifier to those  of the real  user and group,  to avoid
     problems should smail be setuid to the superuser.

     If file is `-', then smail  does not use a primary configuration file.
     You should use this only for debugging.

-d[number]
     Turn on  debugging.  number sets  the level of  debugging; the default
     level is  one.  No  white space must  separate the option  and number.
     Please note  that -d and  -v are identical; smail  recognizes both for
     historical reasons.

-D file
     Write debugging information into file. Normally, using option -v or -d
     to  generate debugging  output  also disables  background delivery  of
     mail, because  programs should not  continue to write  to the standard
     error after the mail process  exits; however, if you name a debugging-
     output file, background delivery can continue.

-ee
-oee These options  refer to a ``berkenet''  style of error-processing that
     smail does not support.  If used, smail mails an error message back to
     you.

-em
-oem Mail error messages to the sender.  This is the default.

-ep  Write error messages onto the standard-error device.

-eq  If an error  occurs, do not notify the sender  of it.  This only works
     for mail  being delivered  locally: an error  that occurs on  a remote
     host's mail  system still generates a mail message  to the sender.  To
     set this behavior  on both the local host and  a remote host, supply a
     header that reads:

         Precedence: junk

-ew
-oew Mail errors  to the sender,  just as with  option -m. With  some mail-
     delivery programs, this option  asks the program to invoke the command
     write to  write errors onto the sender's screen,  should she be logged
     in.

-F fullname
     Set to  fullname the full name  of the sender for  incoming mail.  Use
     this option  only if you  wish to use  smail to receive  a single mail
     message from the standard input.

-f sender
     Set to sender the address for  incoming mail.  Use this option only if
     you  want smail  to receive  a single mail  message from  the standard
     input.

-h number
     Set  to number  the hop  count  for a  message.  If  this command-line
     option is  not used, smail computes  the hop count from  the number of
     Received: fields in the message's header.  smail uses the hop count as
     a primitive method of detecting an  infinite loop: if the hop count is
     too large, smail rejects the mail.

     NB, an  infinite loop occurs  when two sites  each think that  a given
     user resides on  the other.  A message mailed to  that user will ping-
     pong between  the sites;  unless the  message is stopped  somehow, its
     header can grow infinitely large.

-I   Use the ``hidden-dot'' algorithm when reading a message.  If a message
     contains a  line that begins  with one or more  periods, smail removes
     that  leading  period;  a  line  that  consists  of  a  single  period
     terminates  the  message.   This option  is  always  set for  messages
     received via SMTP.

-i   A line that consists of a single period does not terminate an incoming
     message.   This is  the default  if  you invoke  smail under  the name
     rmail.

-m   If  a user  mails a  message  to an  alias list  or mailing  list that
     includes  her name,  send a  copy  of the  message to  that user.   By
     default, if the user mails a message to a list that includes her name,
     smail does not send a copy of a message back to her.

-N   Disable delivery  of a message.  smail  performs all other processing,
     and  the transport  programs are  expected to go  through most  of the
     steps involved  in delivery.  Use  this option when you  wish to debug
     smail but do not want to have the messages delivered.

-n   Do  not process  aliases.   With this  option, smail  will not  expand
     entries  in alias  files;  however, it  will still  expand entries  in
     mailing-list files and forwarding files.

-oC file
     See option -C, above.

-odb If mail is  to be delivered, deliver it in  the background.  Note that
     background delivery is not currently supported in the SMTP modes: mail
     is delivered in the foreground.

-oD file
     Use   file   as   the  directors   file,   instead   of  the   default
     /usr/lib/mail/directors.  smail resets  the effective  user  and group
     identifiers to  those of  the real user  and group, to  avoid problems
     should an installation setuid smail to the superuser.  If file is `-',
     smail does not  read a directors file.  Use this  option only when you
     are debugging smail.

-odf If mail is to be delivered, deliver it in the foreground.

-oE file
     Use file  as the delivery-retry  control file, instead  of the default
     /usr/lib/mail/retry.  smail  resets   the  effective  user  and  group
     identifiers to  those of  the real user  and group, to  avoid problems
     should an installation setuid smail to the superuser.  If file is `-',
     smail does not  read a retry file.  Use this  option only when you are
     debugging smail.

-oep See option -ep, above.

-oeq See option -eq, above.

-oI  See option -I, above.

-oi  See option -i, above.

-oL directory
     Use directory as the library  directory -- that is, the directory that
     holds   configuration  files   and  mailing-list   directories.   This
     overrides  the default  value compiled into  smail through  its option
     smail_lib_dir (under COHERENT /usr/lib/smail), as well as any name set
     in a configuration file.

-oMr sender_proto
     Use sender_proto  as the protocol  by which sending  host delivers the
     mail message.  You can include this value in expansion strings via the
     variable $sender_proto.

-oMs sender_host
     Set to sender_host the system that can send the mail message.  You can
     include this value in expansion strings via the variable $sender_host.
-om  See option -m, above.

-oQ file
     Set the path name of the host-name qualification file to file, instead
     of the default  /usr/lib/mail/qualify. smail resets the effective user
     and group  identifiers to those of  the real user and  group, to avoid
     problems  should an  installation setuid smail  to the  superuser.  If
     file is `-', smail does not read a qualify file.  Use this option only
     when you are debugging smail.

-oR file
     Use   file   as    the   router   file,   instead   of   the   default
     /usr/lib/mail/routers.  smail  resets  the  effective user  and  group
     identifiers to the real  user and group identifiers, to avoid problems
     should an installation setuid smail to the superuser.  If file is `-',
     smail does not read a router  file.  Use this option only when you are
     debugging smail.

-oT file
     Use   file   as   the  transport   file,   instead   of  the   default
     /usr/lib/mail/transports.  smail resets the  effective user  and group
     identifiers to  those of  the real user  and group, to  avoid problems
     should an installation setuid smail to the superuser.  If file is `-',
     smail does not  read a transport file.  Use this  option only when you
     are debugging smail.

-oU  Tell smail to report memory usage when it exits.

-oX mail-service
     Tell smail to  listen for SMTP requests on the  TCP/IP service or port
     mail-service.  You  can  use  this  option  with -bd  mode  to  define
     alternate debugging  versions of  smail's SMTP  listening daemon; this
     can be useful when you test a new installation.

     Please  note that  because COHERENT does  not yet  support networking,
     this option does nothing.

-Q
-odq Spool incoming  messages, but do  not deliver them  until later queue.
     This  mode of  operation is  somewhat more efficient  in terms  of CPU
     usage, but slows down the flow of mail.

-q[interval]
     Force  smail  to  process  its  input  spool directory.   If  you  set
     interval,  smail  continually checks  its  input-spool directory,  and
     sleeps  for  interval  between  checks.   interval  is a  string  that
     consists  of a  number followed  by  one of  the following  letters to
     indicate unit of time:

         s   seconds
         m   minutes
         h   hours
         d   days
         w   weeks
         y   years

     For  example, option  -q2h30m  tells smail  to check  its input  spool
     directory every  two hours and  30 minutes.  This flag  is useful with
     the -bd mode of operation, as it awakens the daemon process after each
     interval  to process  the  queue.  This  is  smail's  default mode  of
     operation when you invoke it under the name runq.

-r sender
     See option -f, above.

-t   Extract addresses  from the To:,  Cc:, and Bcc: fields  of the message
     header.  This is useful for  mailers that do not compute the recipient
     addresses  themselves.   In  this mode,  the  addresses  given on  the
     command  line will  not receive  mail, even as  a result  of expanding
     aliases or forwarding  addresses.  smail ignores this option unless it
     is in  the mode set by  command-line option -bm (which  is the default
     mode).

-V   Print the version smail onto the standard output.

Normal Use

A user agent can submit new mail message by invoking smail and passing it a
message via the standard input.  For  example, mailers such as mail and elm
submit mail by invoking smail with a command such as

    smail -em -i address ...

Because smail also works correctly if  invoked as sendmail, it is common to
install  smail  as  /usr/lib/sendmail, so  that  existing  binaries on  BSD
systems, or other systems that currently run sendmail, need not be modified
to run smail  instead.  This also lets you run  applications that have been
configured to  send mail  via sendmail  without modifying their  sources or
recompiling.

Some user  agents, such as GNU  Emacs, may wish to  have smail decipher the
recipient list  from the  header.  These programs  can invoke smail  with a
command, such as:

    smail -em -t -i

To receive mail over UUCP, uuxqt invokes the command rmail, which is a link
to smail. rmail can also be another program that invokes smail directly as:

    smail -em -i -fsender-address recipient address ...

An alternative  method of receiving  mail over UUCP is  through the command
rsmtp, which receives batched SMTP  requests.  This can be used between two
sites running smail to gain many of the benefits of the SMTP protocol, such
as the ability to use recipient addresses that uux cannot correctly pass to
a remote  rmail program.  For example, an  address that contains quotations
marks  or spaces  cannot be  expected to pass  correctly over  an uux-rmail
link, but will pass correctly over a uux-rsmtp link.

Addressing Under smail

The following describes how smail interprets an E-mail address.

smail understands  domain-style addresses (e.g.,  henry@mwc.com) UUCP-style
path names,  (e.g., mwc!lepanto!henry), and local  addresses (e.g., henry).
It assumes that an address of the form user@domain  is  a  domain  address,
that an address of the form host!address is a  UUCP path, and anything else
is a local address.

When it  parses a mixed address  (that is, an address  that contains both a
`!' and  a `@'), smail gives  precedence to `@' over  `!'.  Thus, it parses
the address  a!b@c as (a!b)@c,  rather than a!(b@c), which  means that mail
addressed to a!b@c is forwarded to system c instead of to system a.

Resolving Addresses

An E-mail address has two  forms: internal and external.  The internal form
of an  address is  what appears  on the To:  line in the  message's header.
This  is the  recipient's address  as typed  by the  person who  mailed the
message.  This  is regardless of  whether the sender  typed the recipient's
full address, or typed an alias  for the recipient.  (For details on how to
use aliases  to address mail messages, see the  Lexicon entry for aliases.)
The external  form of an  address (also called the  message's envelope), is
the address  that smail  passes to the  mail-delivery agent (either  uux or
lmail).

Resolving is the act of  transforming an internal address into an envelope.
It has  two stages: host resolution and  alias resolution.  Host resolution
(also called routing) is how smail figures out the identity of the computer
to which  it must send the  message.  If smail determines  that the message
must be  delivered on your local machine, it  then applies alias resolution
(also called alias expansion) to the  address.  If the address proves to be
an alias,  smail expands  the alias and  again performs host  resolution to
find the machine to which it  should deliver the message.  If, however, the
address names a user on your local machine, then smail hands the message to
the local mailer lmail for delivery.

Although  smail understands  domain-style addresses  (i.e.,  addresses that
contain a `@' and are read from right to left), it can deliver mail only to
UUCP paths  (i.e., addresses that contain `!' characters  and are read from
left to right) and local addresses.  Thus, it must resolve a domain address
into a UUCP path or local address.

To resolve  a domain-style address, smail  must find the route  to the most
specific  part   of  the   domain,  as   specified  in  the   routing  file
/usr/lib/mail/paths. Two degrees of resolution can occur:

Full Resolution
     smail finds the full route to the machine.  In this case, smail either
     tacks the user specification onto  the end of the machine's UUCP path,
     or resolves it into a local address, whichever is appropriate.

Partial Resolution
     smail  finds  a  route  for  only  the right  portion  of  the  domain
     specification; e.g., for

         henry@lepanto.mwc.com

     it finds  mwc.com but cannot  identify lepanto. Here,  smail tacks the
     complete address  (in the form  domain!user) onto the end  of the UUCP
     path.  For  example, if smail finds  that the route to  mwc.com is via
     systems foo, bar, and baz, it constructs the path:

         foo!bar!baz!lepanto.mwc.com!henry

     This  assumes  that  routing program  on  system  baz (perhaps  smail,
     perhaps some  other program) will recognize  the token lepanto.mwc.com
     as being a domain rather than a host.

It is an  error to route a partially resolved  address to the local host (a
null UUCP  path), because the  local host is responsible  for resolving the
address more fully.

The  command-line option  -r  tells smail  to  attempt to  route the  first
(leftmost) component of a UUCP path,  regardless of whether it knows how to
send mail directly to a site  named further to the right in the path.  This
is called always routing. For example, if a mail message is address to

    foo!bar!baz!mwc!lepanto!fred

option -r tells  smail always to route the mail  to foo, even if also knows
how to route mail to mwc.

The command-line option -R tells smail  to route mail to the rightmost host
named on a UUCP path.  This is called reroute routing. Use it if you have a
very up-to-date  routing table,  and wish  to bypass some  obsolete routing
information in the current path.

If file  /usr/lib/mail/paths does not contain a path  to the remote system,
smail forwards mail  to the the host named in  the entry smart_path in file
/usr/lib/mail/config.  This  lets your  system  depend  on another,  better
informed, system  to deliver your mail.  Note that  before you name another
system as  your system's smart_path,  you should get the  permission of the
person  who administers  that system.   Please  note that  if you  start to
forward mail  to a system  without permission, that  system's administrator
may forward your mail to the bit bucket.

After smail  resolves an address, it  reparses the address to  see if it is
now  a UUCP path  or local  address.  If  the new address  turns out  to be
another domain address, smail complains.  This error occurs when an address
partially resolves to the local host.

By default, smail does not alter an explicit UUCP path of any mail message.
If the stated path is unusable (i.e., the next host is unknown), then smail
applies  always-routing  and  attempts  to  deliver  the message  to  first
(leftmost) system named  in the UUCP path.  If this  fails, smail then uses
reroute-routing and  again attempts  to deliver  the message.  If  this too
fails, smail finally attempts to to  find a path to a smart-host and passes
the mail to it.  And if that finally fails, smail mails an error message to
user who  mailed the message,  and abandons any further  attempt to deliver
the message.

Headers

Document RFC822,  which governs Internet mail, demands  that a mail message
contain  certain entries  in its  header.  These  entries include  one that
begins with the string To:, one  that begins with the string From:, and one
that begins  with the string Date.  If a message's header  does not contain
one or more of these entries, smail inserts it.

Build the From: Line of a Message

The header of  a mail message includes a line  that begins From:. This line
names  the  user  who  originated  the  message.  This  line  is  extremely
important, as it will read by  users and programs on the recipient's system
to identify the sender, and possibly reply to the message.

smail  collapses the  From_ and  >From_ lines within  a mail  message to
generate a simple  ``from'' argument, which it then uses  to create its own
From: line.  This processing  sometimes is called from-ming a message.  The
following gives the rules for from-ming:

-> First, it concatenates all  hosts named on remote from lines, separating
   them from each other by `!'s.

-> It appends  onto that  concatenated address,  the address from  the last
   From_ line.

-> If that address is in domain format (i.e., the form user@domain),  smail
   rewrites it in bang-path format (i.e., the form domain!user).  If a host
   or domain names the local system, smail ignores it.

-> Finally, smail removes redundant information from the From_ line.

smail generates its  own From_ line.  For mail that  is to be forwarded via
UUCP, smail generates a line of the form remote-from host; host is the UUCP
host name  (not the domain name),  so that From_ can  indicate a valid UUCP
path, thus leaving the sender's domain address in From:.

Undeliverable Mail

smail  returns to  sender all  mail  that is  undeliverable.  A  message is
declared to be undeliverable if the user is unknown, or if the user resides
on an unknown host.

Logging

smail uses two log files:

/usr/spool/smail/log/logfile
     The log of every mail  message that your system receives.  Please note
     that if your system is busy, this file will quickly become very large.
     You should embed the command /usr/lib/mail/savelog in root's cron file
     to  ensure  that this  file  is truncated  and  saved regularly.   For
     details on savelog or cron, see their articles in the Lexicon.

/usr/spool/smail/log/paniclog
     The log of every mail that  created a panic situation.  If your system
     is configured properly, this file will never become large.

Registered Domains and Subdomains

You may wish  to register your domain with the  NIC.  This will give you an
internationally recognized  e-mail address.  For more  information, send E-
mail to postmaster@internic.net.

Once you  have registered your domain,  you can also set  up subdomains for
other systems,  so they can receive information from  the Internet via your
system.  The  rest of this section discusses how  to describe subdomains to
your system, and related topics.

Let's  say that  you have  registered your  domain, and  you have  named it
mydomain. To route mail systems subordinate to mydomain, do the following:

1.   Insert the following entry into /usr/lib/mail/paths:

         .mydomain.com  %s 50

     This tells smail that the local host (i.e., your machine) must resolve
     that any  address that ends in  the suffix .mydomain.com, or  it is an
     error.

2.   For each site  in mydomain, create two entries in /usr/lib/mail/paths.
     For example, for the site foo.mydomain.com, create the entries:

         foo foo!%s  200
         foo.mydomain.com  foo!%s  200

     If  the site  bar.mydomain.com is fed  by the  route froboz!florp!bar,
     insert these lines into paths:

         bar froboz!florp!bar!%s  200
         bar.mydomain.com  froboz!florp!bar!%s  200

Note that  you do not have  to register subdomains with  the NIC.  Once you
register the  top-level domain  with the NIC,  you control the  entire name
space -- you can subdomain to your heart's content.

The only restrictions on subdomaining may be with your Internet Nameserver.
Most  nameservers for  UUCP domains publish  a ``wildcard''  mail exchanger
(MX) record, that essentially says, ``send everything for *.mydomain.com to
this Internet  gateway.'' However, some nameserver  managers require you to
register every  site in your domain,  for which they provide  a separate MX
record.  The advantage  of this scheme is that anybody  on the Internet who
sends  mail to  your domain  immediately receives an  error message  if the
message is  addressed to a non-existent site.  For  details, check with the
person who manages your nameserver.

To  route for  an  entire subdomain  (e.g.,  .subd.mydomain.com), you  must
choose  a gateway  for that  domain (e.g.,  gateway.subd.mydomain.com), and
then use a line like this:

    .subd.mydomain.com gateway!%s  200

smail automatically  chooses the  longest subdomain  match it can  find, so
this rule applies before the .mydomain.com %s rule.

Note that the gateway need not  be in the subdomain itself.  You could have
a line elsewhere in the paths file on mydomain that says:

    gateway.mydomain.com  gateway!%s  200

Your main  gateway may also have information  about machines in subdomains,
although  this is  not necessary.   For instance, if  your main  machine is
directly connected  to a machine in  a subdomain, you may  want to put this
information into  paths, so the  mail will not  go through the  gateway for
that domain.

For  example,   the  machine  smith.subd.mydomain.com   might  be  directly
connected to your master gateway, mydomain.com:

    smith  smith!%s  200
    smith.subd.mydomain.com smith!%s  200

Without this  rule, mail for  smith would be queued  for forwarding through
gateway.subd.mydomain.com.

Compatibility With sendmail

smail  was  designed  to be  a  plug-in  replacement  for  the BSD  program
sendmail, in  that external programs  can call smail  in the same  way that
they  call  sendmail   and  expect  similar  results.   However,  smail  is
completely  different internally and  has entirely  different configuration
files.  As a  result, the option -o to smail  only sets a few configuration
parameters that were believed to be commonly used by other programs.  Also,
for convenience, some new  (upper-case only) parameters are defined only in
smail. smail ignores attempts to use this flag to set other options.  For a
complete list of  the -o options that smail recognizes,  see the section on
command-line options, above.

For compatibility  with other software  systems (in particular,  the Taylor
UUCP package),  COHERENT links smail to  command /usr/lib/sendmail. Thus, a
program that expects to use sendmail can use smail without being recompiled
or reconfigured.

Configuration Files

For most  sites, the configuration  compiled into smail  is sufficient, and
thus no configuration files are needed.  However, you can use any or all of
the following optional configuration files to restructure how smail behaves
on your system:

/usr/lib/mail/config
     General   configuration.    This   file   can   override   compiled-in
     configuration,   including  the   names  of   any  of   the  following
     configuration files.

/usr/lib/mail/directors
     Configuration file  for smail directors, i.e.,  configured methods for
     resolving local addresses.

/usr/lib/mail/routers
     Configuration  file for  smail routers,  i.e., configured  methods for
     resolving or routing to remote hosts.

/usr/lib/mail/transports
     Configuration for  smail transports, i.e., configured  methods of mail
     delivery.

The  contents of  file  config dictate  how smail  configures its  internal
workings  -- where  it looks  to find other  configuration files,  where it
should send error messages, and so on.  The contents of routers, directors,
and transports together  tell smail how to deliver mail  both on your local
system and on remote systems.  The following describes how these files work
together.

When  smail is  given a  list  of addresses  to which  a message  is  to be
delivered, it  processes the list  iteratively until it produces  a list of
resolved addresses.   When an  address is  resolved, smail will  know which
transport it  must use to deliver  the message to the  person or persons to
whom  it is  addressed,  and all  data  that this  transport requires.   To
accomplish this, smail goes through the following steps:

A. smail first parses each address to  find a host name, called the target,
   and the remaining part of the address, called the remainder.

   As a  simple example, in the address  tron@uts.amdahl.com, the host part
   uts.amdahl.com is  the target and  tron is the  remainder.  Likewise, in
   the  address sun!amdahl!tron,  the target  is sun  and the  remainder is
   amdahl!tron.

B. smail then shows  each address to directors, in the  order given in file
   /usr/lib/mail/directors, until  one of the directors  says that it knows
   what to  do with that  address.  That director  can either return  a new
   list of addresses, or put the address onto a list of resolved addresses.
   If new addresses are produced, smail places them onto the input list, to
   be processed from step A.

C. When an  address has passed  through step B,  smail shows it  to various
   routers,  in the  order  given in  file  /usr/lib/mail/routers, until  a
   router can  match the  target name  for the address.   If no  router can
   match the  complete target, then  smail selects the  router that matches
   the longest portion of the target.  The router names the transport to be
   used to deliver the message to that address, plus some other information
   that  the  transport requires  (e.g.,  the next  host  and next  address
   values).  The  information as to which transport to  use can come either
   from  the definition  of  the router,  from  a method  file,  or may  be
   specified by the router specifically.

When all addresses have been resolved,  smail sorts them and passes them to
transports.  The transport then delivers the message to the addresses it is
given.

Host  names  and local  user-names  are matched  independent  of case;  for
example, ``Postmaster'',  ``POSTMASTER'', and ``postmaster''  are in effect
all  the same.   In addition,  smail keeps  an internal  hash table  of all
regular recipient  addresses, that  is, all  addresses that do  not specify
files or  shell commands.  This table is used  to discard duplicate regular
recipient addresses.   This hash table is independent of  case, as well, so
that  the  address Postmaster@SRI-NIC.ARPA  is  considered  a duplicate  of
postmaster@sri-nic.arpa.

Other Files and Directories

smail also uses the following configuration files:

/usr/lib/mail/qualify
     Configuration file for host-name qualification.
/usr/lib/mail/retry
     Optional delivery retry configuration file, i.e., minimum time between
     retries and maximum time to retry before giving up.

smail reads the  following files to learn how to  redirect mail locally and
to give paths to remote sites:

/usr/lib/mail/aliases
     Aliases for mail addresses.
/usr/lib/mail/paths
     Paths to remote hosts.
/usr/lib/mail/lists
     Mailing-list files.
/usr/spool/mail
     The directory that holds each user's mailbox file.
$HOME/.forward
     Forwarding address or addresses for a given user.

smail uses the following directories to hold incoming mail messages and its
work files:

/usr/spool/smail
     Directory that holds spool directories and work files.
/usr/spool/smail/input
     Spool directory for incoming messages.
/usr/spool/smail/error
     Directory that  holds mail messages that failed for  a reason that the
     site administrator should investigate.
/usr/spool/smail/msglog
     Directory that holds transaction logs for individual messages.
/usr/spool/smail/lock
     This directory holds  smail's input lock files.

The following  files log  smail's  activity.  Please note  that these files
will grow without end.  Your system's system administrator should check and
truncate  these files  from time  to  time.  She  can also  use the  script
/usr/lib/mail/savelog to  manage these files; for  details, see the Lexicon
entry for this command:

/usr/spool/smail/log/logfile
     A log of  smail's transactions.
/usr/spool/smail/log/paniclog
     A log of configuration or system errors encountered by smail.

See Also

commands,
mail [command],
mail [overview],
mailq,
rmail,
rsmtp,
runq,
savelog,
smtpd

Diagnostics

If all  goes well, smail  returns zero to  the shell when it  exits.  If an
error occurs, it returns a value other than zero.  The meaning of each code
is set in  smail's source file exitcodes.h, as follows:

EX_USAGE.......Error in command-line usage
EX_DATAERR.....Data-format error
EX_NOINPUT.....Cannot open input file
EX_NOUSER......Addressee unknown
EX_NOHOST......Host unknown
EX_UNAVAILABLE.Service unavailable
EX_SOFTWARE....Internal software error
EX_OSERR.......System error
EX_OSFILE......Critical OS file missing
EX_CANTCREAT...Cannot create (user) output file
EX_IOERR.......Error in file I/O
EX_TEMPFAIL....Temporary failure; user can retry
EX_PROTOCOL....Remote error in protocol
EX_NOPERM......Permission denied

If you invoke smail with its option -bd, then the message

    bind() failed: address already in use

means that another process is already listening to the SMTP socket.

Notes

Many mail  bugs are not smail  bugs.  smail cannot help  it if remote sites
trash your mail messages.

Setting the  input spool directory processing interval to  a period of more
than  2,147,483,647  seconds  will  result  in  an  incorrectly  calculated
processing interval -- and is a rather silly thing to do at any event.

Copyright © 1987, 1988 Ronald S. Karr and Landon Curt Noll.  Copyright
© 1992 Ronald S. Karr.

For  details on  the distribution rights  and restrictions  associated with
this software, see file COPYING, which  is included with the source code to
the smail system; or type the command:

    smail -bc.