1.  Setting up Run-time Configuration Files

     The  smail3.1  binary is preloaded with a complete con-
figuration and needs no run-time configuration files.   This
preloaded  configuration  file is tunable over a small range
through the EDITME file, and should be sufficient  for  many
sites.  However, if this configuration is not sufficient for
your site, or if you wish  to  define  a  router  that  uses
method  files,  then  you  can  write run-time configuration
files to adapt smail to fit your needs.

1.1.  Types of Run-time Configuration Files

     There are five types of run-time configuration files:

     o    one or two config files, used to set values for  a
variety of smail variables,

     o    a directors file, describing the rules for resolv-
ing local addresses,

     o    a routers file, describing the rules for resolving
remote addresses,

     o    a transports file, describing the possible methods
for performing delivery,

     o    and zero or more method files, which  match  hosts
to transports.

The  following  sections  give  overviews  of the formats of
these files, with examples of their  use.   For  a  complete
format description see the man page smail(5).

1.1.1.  Config Files

     Any  machine  may have a primary and a secondary config
file which redefines the values for a number of smail  vari-
ables.   These  files  can  be  used to define names for the
localhost, define where files reside, setup the  values  for
site-definable  message  header fields and more.  Values set
in the primary config file override values predefined in the
smail binary.  Values set in the secondary config file over-
ride values defined in the smail binary or  in  the  primary
configuration  file.  Also, the name of the secondary config
file can be redefined in the primary configuration file.

     The capability for having two such files is  useful  in
networked  environments  with  distributed filesystems.  For
example, on the Sun network at Amdahl Corp., we  define  the
name    of    the   primary   configuration   file   to   be
/usr/local/lib/smail/config which  is  found  on  our  file-
servers.   This  file  is maintained by the group that main-
tains the mailers running on all of the Suns.   The  primary
configuration  file  defines  a secondary configuration file
named /private/usr/lib/smail/config.  If such a file  exists
on  a  given  workstation,  it  can  be used to redefine the
mailer behavior on that workstation without  requiring  dif-
ferent binaries.

     Because this second configuration file can redefine the
paths to any other  configuration  file  or  directory,  any
aspect of the mailer behavior can be changed.  Thus, a gate-
way machine can use the same primary config  file,  director
file  and  transport  file as the other suns while using its
own private router file.  In addition, a machine on which  a
new delivery agent is being tested can define a private con-
fig file that points to its own router and transport  files.

     The  format  for  either  config  file consists of text
records that set a variable equal to some value.  To  set  a
variable to a string or numeric value, use the form:

     variable = value

For example, the file

     postmaster = tron@glotz.uucp
     domains = wall.com
     spool_mode = 0664

sets   the   default   address   for   the   postmaster   to
``tron@glotz.uucp'', sets the  run-time  equivalent  of  the
EDITME variable DOMAINS to ``wall.com'' and sets the permis-
sion mode for spool files to allow the file owner and  group
to write it.

     Boolean attributes can be set using the notation:

     +boolean-variable

and can be reset using the notation:

     -boolean-variable

The ``-variable'' notation can also be used to set a numeric
variable to zero and to unset a value for a string variable.
For  example,  the following config file disables the use of
an external transport file and tells smail  that  configura-
tion files are not optional:

     -transport_file
     +require_configs

Comments  using  the  shell `#' notation and blank lines are
allowed in  config  files.   In  addition,  records  can  be
extended  by  including white space at the beginning of suc-
cessive lines.  For example, the following config file  sets
the  Received:  header field to use for messages to a multi-
line value and sets the name of a user that has  few  access
capabilities:

     # Use a verbose format for the Received: header field
     received_field = "Received: by $primary_name
with smail ($version_string)
id <$message_id@$primary_name); $date"

     nobody = unknown         # unknown has few access capabilities


     The  complete  list of variables that can be set in the
config files is described in the man page smail(5).

1.1.2.  Directors, routers and Transports Files

     The directors, routers and transports  files  all  have
the  same  format.   These files describe entries in a table
where each entry describes the attributes for one  director,
router  or  transport.  The order of entries in the director
and router files is import, in that  directors  and  routers
are  called  in the order stated in the table.  The order of
entries in the transport file is not important.

     An entry in one of these files defines:

     o    a name by which that entry is known.

     o    a driver which implements the  function  for  that
entry.

     o    a set of generic attributes from a set that can be
applied to any entry in the file.

     o    a set of driver-specific attributes,  from  a  set
that  can  be applied only to entries that use the
specified driver.

     As an example, the director file entry below  specifies
the attributes for a director that reads aliases from a file
/private/usr/lib/aliases:

     # read aliases from a file private to one machine on the network
     private_aliases:
driver=aliasfile, owner=owner-$user ;
file=/private/usr/lib/aliases

This entry is named private_aliases, and  depends  upon  the
low-level  director  driver routine named aliasfile.  Errors
found while processing addresses found by this director  are
sent  to  an  address formed by prepending ``owner-'' to the
name of the alias, and these the aliases are stored  in  the
file   /private/usr/lib/aliases.    The  aliasfile  director
driver implements a general mechanism for looking up aliases
stored in a database.  By default, this database is simply a
file containing ASCII records in no particular  order.   The
file /private/usr/lib/aliases could contain:

     # tron is the postmaster for this particular machine
     Postmaster: tron

     # list the users that are likely to use futatsu frequently
     Futatsu-Users:
tron,# Ronald S. Karr
chongo,        # Landon Curt Noll
deleanu        # Jay Deleanu

Notice that, as with other configuration files, an alias can
be extended across multiple lines  by  beginning  successive
lines with whitespace.

     The  separation  between generic attributes and driver-
specific attributes mirrors the internal design of smail3.1.
Above  the driver level, there exist routines that implement
aspects of drivers,  routers  and  transports  that  do  not
depend upon the specific means for performing the operation.
These higher-level functions can be manipulated through  the
generic  attributes.   On  the  other hand, the drivers that
actually perform these operations accept a different set  of
attributes  to  control  their  behavior.   In the case of a
driver thats read or writes to a file, a file attribute usu-
ally  exists.   In the case of a driver that executes a pro-
gram a cmd attribute usually exists to specify how that pro-
gram is to be invoked.

     The  complete  description  of the director, router and
transport files is  contained  in  the  smail(5)  man  page.
Included  in  the  man  page is a description for all of the
drivers that are included in the smail3.1  source  distribu-
tion.  The following sections describe the preloaded config-
uration.  To serve as examples, these sections include  con-
figuration  files  which are the equivalent of the preloaded
configuration.

1.2.  The Preloaded Configuration

     In order to gain a better understanding of how configu-
ration files can be used to change the behavior of smail, it
is useful to know what smail will do if run-time  configura-
tion  files  were not used.  This behavior is defined in the
preloaded  configuration  which  is  in  the   source   file
src/default.c.

     The preloaded configuration currently comes in two fla-
vors: one flavor is for  systems  that  have  Berkeley-style
networking  with  TCP/IP, the other flavor is for sites that
do not have such networking.  The difference between the two
is that a networking configuration defines two extra routers
to match network hosts  by  name  or  by  internet  address.
Also,  one  extra transport is defined to deliver using SMTP
over a TCP/IP connection to a network host.

1.2.1.  The Preloaded Director Configuration

     If a directors configuration file is not found at  run-
time,  then  the  default  pre-loaded configuration is used.
The default director configuration  supports  the  following
directors: For local addresses of the form :include:filename
these addresses will be expanded into a  list  of  addresses
contained in the given ASCII file.  The files to which these
addresses refer are called mailing list files.  This form of
local  address can come from any alias file, forward file or
mailing list file.  Users cannot supply such addresses them-
selves.   This  director  scans  for  entries  in  an  alias
database.  The name of this  database,  and  the  method  by
which  this  file  is  searched can be changed in the EDITME
file.  As distributed,  aliases  are  taken  from  the  file
/usr/lib/aliases,  which  is  an  unsorted  ASCII text file.
This alias file is optional, and is ignored if it  does  not
exist.   Any errors found while resolving addresses produced
by an alias  are  mailed  to  an  address  with  the  string
``owner-''  prepended  to  the  name of the alias, if such a
local address is defined.  A user  may  have  a  file  named
.forward  in  his  or  her  home  directory.  If such a file
exists it will be scanned for addresses.  Any mail to a user
that  has  such  a  file will be redirected to the addresses
contained within it.  The file can contain  addresses  which
specify  files or shell commands as recipients.  If the for-
ward file is owned by root or  by  the  user  himself,  then
deliveries  to  any  shell  commands  or files are performed
under the user's user and group id.  Any errors found  while
resolving  this list of addresses are mailed to the Postmas-
ter.  In a forward file for the  user  root,  deliveries  to
shell  command  and  file  addresses  are performed under an
unprivileged user and group ID.  The same  is  true  in  the
case  of forward files that were not owned by root or by the
given user.  Finally, shell command and file  addresses  are
not  allowed  at  all  in forward files that are in remotely
accessible directories.  The mailbox file  for  a  user  may
contain a line of the form

     Forward to address, address ...

as an alternate method for a user to forward his mail.  Only
one line is read from  this  file  so  addresses  cannot  be
placed  across multiple lines.  The comments that apply to a
forward file also apply to  this  use  of  a  mailbox  file,
except  that  it  is assumed that a mailbox file is not in a
remotely accessible directory.  A user is matched  by  name,
either  in  upper  or lower case, with delivery to that user
being performed using a transport by the name of  ``local''.
A  user  can also be matched by name if the username is pre-
fixed by ``real-''.  Delivery is performed  by  a  transport
named  ``local''.  Mailing list files can be created under a
mailing list directory.  This is  a  directory  named  lists
under  the directory containing smail utilities and configu-
ration files (typically /usr/lib/smail).  A new mailing list
can  be  creating  by  making a file in this directory which
contains a list of addresses.  The  basename  of  this  file
determines  the local address which will be expanded to this
list of addresses.  For example,  a  file  named  info-smail
could  be created with a list of recipient addresses for the
``info-smail'' mailing list.  Errors in delivering  to  this
list  of  addresses  are  mailed to a local address with the
name ``owner-'' prepended to the basename of  the  file,  if
such  an  address  is  defined.   If  a local address is not
matched by any other means, mail to that address can be sent
to  another  machine  using  the  smartuser  director.   The
address to which this mail is redirected can be defined in a
config  file  by setting the variable smart_user.  For exam-
ple, the following config file line could be used  to  redi-
rect mail to the host amdahl.uts.amdahl.com:

     smart_user = $user@amdahl.uts.amdahl.com

If this variable is not set, then the smart_user director is
ignored.

     The order of entries in the  director  file  determines
the  order in which operations are attempted.  If a director
matches an  address  then  no  other  directors  are  called
attempted  to  expand  or  resolve that address.  A director
file which is equivalent to the preloaded configuration is:

     # aliasinclude - expand ":include:filename" addresses
     #    produced by alias files
     aliasinclude:
driver = aliasinclude,   # use this special-case driver
nobody;        # associate nobody user with addresses
     #  when mild permission violations
     #  are encountered

copysecure,    # get permissions from alias director
copyowners     # get owners from alias director


     # forwardinclude - expand ":include:filename" addresses
     #    produced by forward files
     forwardinclude:
driver = forwardinclude, # use this special-case driver
nobody;

copysecure,    # get perms from forwarding director
copyowners     # get owners from forwarding director

     # aliases - search for alias expansions stored in a database
     aliases:
driver = aliasfile,      # general-purpose aliasing director
-nobody,       # all addresses are associated
     # with nobody by default, so setting
     # this is not useful.
owner = owner-$user;     # problems go to an owner address

file = /usr/lib/aliases,
modemask = 002,
optional,      # ignore if file does not exist
proto = lsearch


     # dotforward - expand .forward files in user home directories
     dotforward:
driver = forwardfile,    # general-purpose forwarding director
owner = Postmaster,      # problems go to the user's mailbox
nobody,
sender_okay;   # sender never removed from expansion

file = ~/.forward,       # .forward file in home directories
checkowner,    # the user can own this file
owners = root, # or root can own the file
modemask = 002,# it should not be globally writable
caution = daemon:root,   # don't run things as root or daemon
# be extra careful of remotely accessible home directories
unsecure = "~ftp:~uucp:~nuucp:/tmp:/usr/tmp"


     # forwardto - expand a "Forward to " in user mailbox files
     #
     # This emulates the V6/V7/System-V forwarding mechanism which uses a
     # line of forward addresses stored at the beginning of user mailbox
     # files prefixed with the string "Forward to "
     forwardto:
driver = forwardfile,
owner = Postmaster, nobody, sender_okay;

file = /usr/mail/${lc:user}, # the mailbox file for System V
forwardto,     # enable "Forward to " function
checkowner,    # the user can own this file
owners = root, # or root can own the file
modemask = 0002,         # under System V, group mail can write
caution = daemon:root    # don't run things as root or daemon


     # user - match users on the local host with delivery to their mailboxes
     user:     driver = user;# driver to match usernames

transport = local        # local transport goes to mailboxes


     # real_user - match usernames when prefixed with the string "real-"
     #
     # This is useful for allowing an address which explicitly delivers to
     # a user's mailbox file.  For example, errors in a .forward file
     # expansion can be delivered here, or forwarding loops between
     # multiple machines can be resolved by using a real-username address.
     real_user:
driver = user;

transport = local,
prefix = "real-"         # for example, match real-root


     # lists - expand mailing lists stored in a list directory
     #
     # mailing lists can be created simply by creating a file in the
     # /usr/lib/smail/lists directory.
     lists:    driver = forwardfile,
caution,       # flag all addresses with caution
nobody,        # and then associate the nobody user
owner = owner-$user;     # system V sites may wish to use
     # o-$user, as owner-$user may be
     # too long for a 14-char filename.

# map the name of the mailing list to lower case
file = lists/${lc:user}


     # smart_user - a partially specified smartuser director
     #
     # If the config file attribute smart_user is defined as a string such
     # as "$user@domain-gateway" then users not matched otherwise will be
     # sent off to the host "domain-gateway".
     #
     # If the smart_user attribute is not defined, this director is ignored.
     smart_user:
driver = smartuser;      # special-case driver

# do not match addresses which cannot be made into valid
# RFC822 local addresses without the use of double quotes.
well_formed_only


1.2.2.  The Preloaded Router Configuration

     If a routers configuration file is not  found  at  run-
time,  then  the  default  pre-loaded configuration is used.
The default  router  configuration  supports  the  following
routers:  This router will match hosts specified as internet
addresses enclosed in square  brackets.   Delivery  to  such
hosts   is   always   performed  using  the  smtp  transport
(described in a later section).  Any  hostname  with  square
brackets that does not match the form of an internet address
will be considered an error.   An  example  of  an  internet
address is [192.2.12.142].  This router is only available on
machines that support BSD compatible networking  facilities.
This  will  match  internet  hostnames  that  can be matched
through the gethostbyname(3N) library routine.   Often  this
library function will match any host in the file /etc/hosts.
Deliveries to hosts matched with this router are always per-
formed  using  the smtp transport (described in a later sec-
tion).  This router is only available on machines that  sup-
port  BSD compatible networking facilities.  A path database
is used to match hosts for which  routes  are  known.   Nor-
mally,   this   path   database   is   stored  in  the  file
/usr/lib/smail/paths.  Often this database will be generated
from   map  files  distributed  over  the  USENET  newsgroup
comp.mail.maps, though path databases can  also  be  created
through  other  means.   A  paths database associates a path
with specific hostname or domain.  A path is  defined  as  a
set  of  hostnames  separated  by  single exclamation points
(`!'), with the last host being followed by the string `%s'.
An example of a simple path database is a file containing:

     .curds.org  curds-vax!%s
     .whey.edu   foo!whey-3b20!%s
     bar         foo!bar!%s
     foo         foo!%s

Each  path in this database specifies the sequence of hosts,
from first to last, through which a mail message  must  pass
to reach the host specified on the left-hand-side.  For more
information  on  path   databases   see   pathalias(8)   and
mkpath(8).   Depending  upon  the configuration specified in
the EDITME configuration file, this path file may need to be
sorted,  or  it may be stored in a database created with the
dbm(3X) library routines (see mkdbm(8)  for  information  on
how  to  create these databases).  Delivery to hosts matched
with this router is performed using the uux transport, which
is    described   in   a   later   section.    The   program
/usr/bin/uuname is used to obtain a list of sites  that  the
local  host communicates with over UUCP (see uucp(1)).  This
router compares  hostnames  against  this  list  and  causes
delivery  to be performed using the uux transport whenever a
match is found.  If a hostname is not matched by  any  other
means,  mail  to  that  host  can be sent to another machine
using the smarthost router.  The  path  through  which  this
mail  is  redirected can be defined in a config file by set-
ting the variable smart_path.  For  example,  the  following
config  file  line  could  be  used  to redirect mail to the
neighboring host amdahl:

     smart_path = amdahl

If this variable is not set, then the smart_user director is
ignored.  Delivery is performed using the transport named in
the config file variable smart_transport.  If this  variable
is not set then the uux transport is used.

     The  order of entries in the router file determines the
order in  which  operations  are  attempted.   If  a  router
matches  a hostname completely, then no other operations are
attempted to resolve that host.  If a router matches a  host
partially,  as  a domain in the right-hand side of the host-
name, then subsequent routers may  also  find  routes.   The
router  which finds the best match, based on number of char-
acters matched, wins.  In the case of a tie, the router ear-
liest  in  the  router  file  wins.   A router file which is
equivalent to the preloaded configuration file is:

     # inet_addrs and inet_hosts are only defined when BSD networking
     # exists

     # inet_addrs - match domain literals containing literal IP addresses
     #
     # For example, [128.103.1.1] will match harvard.harvard.edu on the
     # internet.  The library routine gethostbyaddr(3N) will be called to
     # see if a reverse mapping to the canonical hostname is available.
     inet_addrs:
driver = gethostbyaddr,  # router to match IP domain literals
transport = smtp;        # deliver using SMTP over TCP/IP

fail_if_error, # fail malformed domain literal addrs
check_for_local# see if this is really the local host


     # inet_hosts - match hostnames with gethostbyname(3N)
     inet_hosts:
driver = gethostbyname,  # match hosts with the library function
transport = smtp


     # paths - route using a paths file, like that produced by the
     #    pathalias program
     paths:    driver = pathalias,# general-use paths router
transport = uux;         # for matches, deliver over UUCP

file = paths,  # sorted file containing path info
proto = bsearch,         # use a binary search
optional,      # ignore if the file does not exist
domain = uucp  # strip ending ".uucp" before searching


     # uucp_neighbors - match neighbors accessible over UUCP
     uucp_neighbors:
driver = uuname,         # use a program which returns neighbors
transport = uux;

cmd = /usr/bin/uuname,   # specifically, use the uuname program
domain = uucp


     # smart_host - a partially specified smarthost director
     #
     # If the config file attribute smart_path is defined as a path from
     # the local host to a remote host, then hostnames not matched
     # otherwise will be sent off to the stated remote host.  The config
     # file attribute smart_transport can be used to specify a different
     # transport.
     #
     # If the smart_path attribute is not defined, this router is ignored.
     smart_host:
driver = smarthost,      # special-case driver
transport = uux# by default deliver over UUCP


1.2.3.  The Preloaded Transport Configuration

     If a transports configuration file is not found at run-
time,  then  the  default  pre-loaded configuration is used.
The default transport configuration supports  the  following
transports:  Deliver to users on the local machine.  Mailbox
files for local users are generally found under  the  direc-
tory  /usr/spool/mail  or under /usr/mail, and have the same
name as the corresponding user.  To  support  the  generally
available  user  interfaces,  such  as Mail(1) and mailx(1),
certain  transformations  are  performed  on  the   message.
Namely,  a  line containing the return address of the sender
and a time stamp is prepended to the message, a  blank  line
is appended at the end, and any line beginning with the word
``From'' will have the character `>' prepended  to  it.   An
example of one of the lines prepended to the message is:

     From amdahl!futatsu!tron Mon Apr 18 16:11:13 1988

In  addition,  a  ``Return-Path:''  header field is inserted
which duplicates the return address of  the  sender.   Local
addresses  which  begin  with a vertical bar character (`|')
are delivered using this transport (the transport name  pipe
is  reserved for this purpose).  The pipe transport executes
a shell command by calling the program /bin/sh.  The message
is  passed on the standard input to this command.  The shell
command is formed by removing  the  vertical  bar  character
from  the  beginning  of  the address.  The alias or forward
address which produced the pipe command address is stored in
the  environment  as  "$ADDR".   Local addresses which begin
with a slash (`/') or a tilde character (`~') are  delivered
using  this  transport  (the transport name file is reserved
for this purpose).  The file transport  appends  to  a  file
identified  by  the  local  address  string.   If  the local
address string begins with a slash, then  it  identifies  an
absolute  path.   If  the string begins with ``~username/'',
then this substring is replaced by the home directory of the
given  user.   If the string begins simply with ``~/'', then
this substring will be  replaced  with  any  home  directory
associated  with  the  address;  e.g.,  a  file address in a
user's ~/.forward file will be associated with  that  user's
home  directory.   The  uux  transport is used as the normal
form of delivery over UUCP.  This transport will deliver  up
to five addresses at a time by calling the program uux(1) to
deliver mail to the program rmail(1)  on  a  remote  system.
The  request is queued, and actual delivery is not attempted
immediately.  To force an immediate attempt to  contact  the
remote site, use the demand transport.  The demand transport
is used to deliver up to five addresses at a time by calling
the  program uux(1) to deliver to a remote rmail(1) program.
In contrast  to  uux  this  transport  forces  an  immediate
attempt to contact the remote site.  The uusmtp transport is
used to deliver using  Batched  SMTP  over  UUCP.   It  will
deliver  to  an unlimited number of addresses by calling the
program uux(1) to deliver to a remote rsmtp(1) program.  The
request  is  queued,  and  actual  delivery is not attempted
immediately.  This transport is used to deliver to an unlim-
ited  number  of  addresses by calling the program uux(1) to
deliver to a remote rsmtp(1) program.  This transport forces
an  immediate attempt to contact the remote site.  For sites
that have  BSD  networking  facilities,  this  transport  is
available,  which performs delivery by opening a TCP/IP vir-
tual circuit to a remote host and engaging in an interactive
SMTP dialogue to perform delivery.

     The  order  of  entries  in  the  transport file is not
important, unless transport  entries  with  duplicate  names
exist.  In this case, the transport earlier in the transport
file is always used.  A transport file which  is  equivalent
to the preloaded configuration file is:

     # local - deliver mail to local users
     #
     # By default, smail will append directly to user mailbox files.
     local:    driver = appendfile,# append message to a file
return_path,   # include a Return-Path: field
local,         # use local forms for delivery
from,# supply a From_ envelope line
unix_from_hack;# insert > before From in body

file = /usr/mail/${lc:user},# use this location for System V
group = mail,  # group to own file for System V
mode = 0660,   # under System V, group mail can access
suffix = "0    # append an extra newline


     # pipe - deliver mail to shell commands
     #
     # This is used implicitly when smail encounters addresses which begin with
     # a vertical bar character, such as "|/usr/lib/news/recnews talk.bizarre".
     # The vertical bar is removed from the address before being given to the
     # transport.
     pipe:     driver = pipe,# pipe message to another program
return_path, local, from, unix_from_hack;

cmd = "/bin/sh -c $user",# send address to the Bourne Shell
parent_env,    # environment info from parent addr
pipe_as_user,  # use user-id associated with address
umask = 0022,  # umask for child process
-log_output    # do not log stdout/stderr


     # file - deliver mail to files
     #
     # This is used implicitly when smail encounters addresses which begin with
     # a slash or twiddle character, such as "/usr/info/list_messages" or
     # perhaps "~/Mail/inbox".
     file:     driver = appendfile,
return_path, local, from, unix_from_hack;

file = $user,  # file is taken from address
append_as_user,# use user-id associated with address
expand_user,   # expand ~ and $ within address
suffix = "0,
mode = 0644


     # uux - deliver to the rmail program on a remote UUCP site
     uux: driver = pipe,
uucp,# use UUCP-style addressing forms
from,# supply a From_ envelope line
max_addrs = 5, # at most 5 addresses per invocation
max_chars = 200;         # at most 200 chars of addresses

# the -r flag prevents immediate delivery, parentheses around the
# $user variable prevent special interpretation by uux.
cmd = "/usr/bin/uux - -r $host!rmail $(($user)$)",
umask = 0022,
pipe_as_sender


     # demand - deliver to a remote rmail program, polling on demand
     demand:   driver = pipe,
uucp, from, max_addrs = 5, max_chars = 200;

# with no -r flag, try to contact remote site immediately
cmd = "/usr/bin/uux - $host!rmail $(($user)$)",
umask = 0022, pipe_as_sender


     # uusmtp - deliver to the rsmtp program on a remote UUCP site
     #
     # The rsmtp program is assumed to to take batched SMTP requests.
     uusmtp:   driver = pipe,
bsmtp,         # send batched SMTP commands
inet,# use internet forms for addressing
-max_addrs,    # there is no limit on the number or
-max_chars;    #  total size of recipient addresses.

# supply -r to prevent immediate delivery, the recipient addresses
# are stored in the data sent to the standard input of rsmtp.
cmd = "/usr/bin/uux - -r $host!rsmtp",
umask = 0022, pipe_as_sender


     # demand_uusmtp - deliver to a remote rsmtp program, polling on demand
     demand_uusmtp:
driver = pipe, inet,
bsmtp, -max_addrs, -max_chars;

# with no -r flag, try to contact remote site immediately
cmd = "/usr/bin/uux - $host!rsmtp",
umask = 0022, pipe_as_sender


     # smtp - deliver using SMTP over TCP/IP
     #
     # Connect to a remote host using TCP/IP and initiate an SMTP conversation
     # to deliver the message.  The smtp transport is included only if BSD
     # networking exists.
     #
     # NOTE:   This is hardly optimal, a backend should exist which can handle
     #    multiple messages per connection.
     #
     # ALSO:   It may be necessary to restrict max_addrs to 100, as this is the
     #    lower limit SMTP requires an implementation to handle for one
     #    message.
     smtp:     driver = smtp,
-max_addrs,
-max_chars, inet

