Seth Woolley's Man Viewer

deliver(8) - deliver - deliver mail - man 8 deliver

([section] manual, -k keyword, -K [section] search, -f whatis)
man plain no title

DELIVER(8)                                                          DELIVER(8)

       deliver - deliver mail(1,8)

       deliver [ options ] address ...

       The Deliver program collects a mail(1,8) message from the standard input and
       delivers it.  Deliver is capable of handling the delivery of all  mail.
       However, Deliver is typically hung off the end of an existing mail(1,8) sys-
       tem, where it handles the delivery of some or all  local  mail(1,8),  a  job
       usually    done    by    /bin/mail(1,8)    (System    V    and    BSD)    or
       /usr/lib/mail(1,8)/mail.local (Xenix).

       The way Deliver handles each message is  controlled  by  shell  scripts
       which,  given the message to be delivered and a list of addresses, pro-
       duce as their output new lists of addresses.  Such scripts, when called
       by  Deliver,  are  called  ``delivery  files.''   Deliver allows a site
       administrator to write(1,2) delivery files with global  effects.   In  addi-
       tion,  each  user may write(1,2) a delivery file(1,n) to control delivery of mail(1,8)
       addressed to himself.

       -b     Interpret arguments as mailbox filenames instead  of  addresses.
              The user who executes Deliver must have write(1,2) permissions on all
              mailbox files.  He may also need write(1,2) permissions on their par-
              ent directories, depending on the existence of the mailbox files
              and the local locking protocol.

       -n     Deliver to the given address(es), but do not  run  any  delivery
              files.   This  option  is  most  useful when Deliver is executed
              recursively, because it cannot cause infinite recursion.

       -A     Collect the message, run delivery files and print  the  resolved
              address(es).   Do  not deliver the message.  Note that when this
              option is specified, Deliver still collects a message  from  the
              standard  input,  because  delivery  files may vary their output
              based on message content.  To test simple delivery files,  redi-
              rect standard input from /dev/null.

       -d     Turn  on  verbosity, collect the message and run delivery files.
              Do not deliver the message.

       -v     Turn on verbosity while performing all tasks,  including  deliv-

       -t     Do not remove temporary files before exiting.

       -l localsender
              Specify  localsender  as  the name of the local sender, that is,
              the name of the user who invoked Deliver.  This option  is  only
              believed  if(3,n) it is a valid user name with a user id equal to the
              real user id of the Deliver process.  If it is invalid, or if(3,n) it
              is  not  specified, then Deliver tries the values of the LOGNAME
              and USER environment variables, and then the login(1,3,5)  name  corre-
              sponding  to  the  tty(1,4)  on which Deliver is running.  If none of
              these names matches the real user id, Deliver looks up the  user
              name that corresponds to its real user id.

       -r sender
              Put  sender  on the generated From_ line.  Default is to use the
              address on the From_ line  in(1,8)  the  input,  or  else  the  local

       -h hostname
              Set the host(1,5) name.  The default is determined in(1,8) a site-specific
              way, typically by asking the kernel.

       -s system delivery file(1,n)
              Specify an alternate  system  delivery  file.   The  default  is

       -p post-user delivery file(1,n)
              Specify  an  alternate  post-user delivery file.  The default is

       -e error(8,n) delivery file(1,n)
              Specify an  alternate  error(8,n)  delivery  file.   The  default  is

       -u user delivery file(1,n)
              Specify  an  alternate  user  delivery  file.   The  default  is
              .deliver (in(1,8) each user's home directory).

       For security reasons, specifying one or more of the options ``-h  host-
       name'',  ``-s  sysdelfile'',  ``-p  postdelfile'', ``-e errdelfile'' or
       ``-u  userdelfile''  disables  setuid  privileges.   That  is,  Deliver
       revokes  its  setuid privileges before doing anything significant, just
       as if(3,n) Deliver had been installed without the setuid bit turned on.

       All command line options are put into environment  variables,  examined
       by  Deliver  on  startup; thus all flags are propagated when Deliver is
       invoked recursively.  Note that setting these environment variables  is
       exactly  equivalent  to specifying the equivalent command line options;
       in(1,8) particular, they can cause Deliver to disable setuid  privileges  as
       described in(1,8) the previous paragraph.

       For mail(1,8) systems based on Smail 2.x, the LMAIL (local mailer) macro can
       be changed to call Deliver.  For mail(1,8) systems based  on  Smail  3.x  or
       sendmail(1,8),  a  similar  arrangement  may  be made; otherwise, individual
       users(1,5) can invoke Deliver by mentioning it in(1,8) their .forward files (e.g.
       ``|/usr/bin/deliver myname'').

       For  Xenix  systems,  Deliver  may  be used as a direct replacement for

       For stock Unix systems, it may be possible to make /bin/rmail a link(1,2) to
       Deliver;  however,  this  configuration  has not been tested and is not
       recommended.  After all, any postmaster  motivated  enough  to  install
       Deliver,  and  who wants something better than the standard /bin/rmail,
       should install Smail 2.x or 3.x.

       When Deliver starts execution, it interprets its arguments  in(1,8)  one  of
       three ways.

       (1)  If  the  -b (mailbox) option is specified, then Deliver interprets
       its arguments as mailbox pathnames.

       (3) If the -n option is specified, then Deliver  interprets  its  argu-
       ments as addresses.

       (3)  If neither the -b nor the -n option is specified, Deliver uses the
       system, user and post-user delivery files (described below)  to  deter-
       mine the address(es) to receive the message.

       After  attempting  delivery,  Deliver looks in(1,8) its list of destinations
       for failures of any kind.  If any failed destinations are found, and if(3,n)
       the  -n  option  is  not specified, Deliver executes the error(8,n) delivery
       file(1,n) with the entire list of failed addresses as its arguments.  If the
       error(8,n) delivery file(1,n) generates any destinations, Deliver attempts deliv-
       ery to them.  However, if(3,n) such delivery fails, Deliver will not re-exe-
       cute the error(8,n) delivery file.

       Delivery  files  are shell scripts executed by Deliver to determine the
       address(es) to receive a message.  Note that delivery files  have  con-
       trol over delivery to users(1,5) and remote addresses, but not over delivery
       to explicitly named(5,8) mailboxes.  (See also the -b option.)

       The default shell used to  execute  delivery  files  is  configuration-
       dependent.   Typically  it is the Bourne shell (/bin/sh).  However, you
       can arrange for Deliver to execute any given  delivery  file(1,n)  with  any
       given  shell  by  starting  the delivery file(1,n) with a ``#!'' line in(1,8) the
       style of Berkeley UNIX.  For example, if(3,n) the first line of  a  delivery
       file(1,n)  is  ``#!/bin/perl'', then Deliver will execute that delivery file(1,n)
       with /bin/perl instead of /bin/sh.

       The four kinds of delivery files are described below.

       system delivery file(1,n)
              The system delivery file(1,n), if(3,n) it exists, is created by the  post-
              master.  By default, it is named(5,8) ``/usr/local/lib/deliver.sys''.
              It controls the delivery of all messages on the system where  it
              is  installed.   It  is  executed  with arguments of the name(s)
              specified on the Deliver command  line.   (Note,  however,  that
              arguments  containing  shell  metacharacters are rejected before
              the system delivery file(1,n) is run.)

       user delivery file(1,n)
              Each user may create a user delivery file(1,n) in(1,8) his home directory.
              By  default,  it is named(5,8) ``.deliver''.  A user delivery file(1,n) is
              always executed with exactly one argument: the name of the  user
              in(1,8) whose home directory the file(1,n) is found.

       post-user delivery file(1,n)
              The  post-user  delivery  file(1,n),  if(3,n) it exists, is created by the
              postmaster.       By      default,       it       is       named(5,8)
              ``/usr/local/lib/''.   It is executed after the sys-
              tem and user delivery files, but before any attempt  at  message
              delivery.   Its arguments are those addresses which are about to
              receive the message, whether  those  addresses  originated  with
              Deliver command line arguments or with a system or user delivery
              file.  This delivery file(1,n) is particularly useful for  implement-
              ing system-wide aliases, since it can modify or delete addresses
              generated by user delivery files, something the system  delivery
              file(1,n) cannot do.

       error(8,n) delivery file(1,n)
              The  error(8,n)  delivery file(1,n), if(3,n) it exists, is created by the post-
              master.  By default, it is named(5,8) ``/usr/local/lib/deliver.err''.
              After  Deliver  has attempted delivery to all requested destina-
              tions, and if(3,n) delivery to one  or  more  of  those  destinations
              failed,  Deliver executes the error(8,n) delivery file(1,n) with arguments
              of all failed addresses.  Note that failed addresses may contain
              whitespace,  shell  metacharacters  or  other  strangeness -- be

       When Deliver runs a delivery file(1,n),  it  monitors  the  delivery  file(1,n)'s
       standard  output  for  delivery  directives,  one  directive  per line.
       Directives can take five forms:

              Append the message to the given  user's  default  mailbox.   The
              location of a user's default mailbox is configuration-dependent.

              Append the message to the specified mailbox in(1,8) the given  user's
              context.  If the mailbox name is not an absolute pathname, it is
              interpreted relative to the given user's home  directory.   Only
              the  superuser  may  request  delivery  to  a mailbox in(1,8) another
              user's context.

              Execute the specified command in(1,8) the given user's  context,  and
              feed  the message to its standard input.  Only the superuser may
              request command execution in(1,8) another user's context.

       user?error(8,n) message
              Do not attempt delivery to the given user.  Diagnostic messages,
              including the bounce notice (if(3,n) any), will include the specified
              message.  Only the superuser may report  an  error(8,n)  for  another

              Send the message with UUCP via the given bang path.

       Note  that the ``user:mailbox'', ``user|command'' and ``user?error(8,n) mes-
       sage'' forms may omit the ``user'' part, in(1,8) which case the current user
       context is assumed.

       When  Deliver  executes  a  delivery  file(1,n), it sets several environment
       variables, listed below.  Note that  these  environment  variables  are
       both set(7,n,1 builtins) and used by Deliver; therefore, all command line options auto-
       matically propagate when Deliver is run recursively (within a  delivery
       file(1,n)).  The environment variable names set(7,n,1 builtins) and used by Deliver are:

       DELPID The  process id of the running Deliver process.  Used by a child
              Deliver to determine its parent's process id.

              The Deliver recursion level.  Each time(1,2,n) Deliver is called recur-
              sively,  this  value is incremented.  When the maximum recursion
              level (default: eight) is  exceeded,  Deliver  assumes  infinite
              recursion and aborts.

              The  command line flags that do not take arguments, if(3,n) any, that
              were specified on the Deliver command line.

              The local host(1,5) name, either the real hostname or a  name  speci-
              fied with the -h option to Deliver.

              The system delivery filename.

              The post-user delivery filename.

              The error(8,n) delivery filename.

              The  user  delivery  filename, relative to the home directory of
              each user.

              The local sender, that is, the user who invoked  Deliver.   This
              value  is not believed by recursive Deliver processes, since the
              user who invokes the child may not be the same as the  user  who
              invoked the parent.

       SENDER The  original  sender  of  the  message.   This value can be the
              address specified with the -r option to Deliver, or the  address
              given in(1,8) the From_ line of the message, or the local sender.

       HEADER The name of the temporary file(1,n) containing the message header.

       BODY   The name of the temporary file(1,n) containing the message body.

       Recursive execution of Deliver is useful, especially when used with the
       the -b (mailbox) and -n (no delivery files) flags.  For example, a user
       may  wish to transform a message body before it is stored in(1,8) a mailbox.
       This may be done with a user delivery file(1,n) and recursive  execution  of
       Deliver.   For example, the following user delivery file(1,n) translates all
       incoming message bodies to lower case, and stores them  in(1,8)  the  user's
       default mailbox:

           ( cat $HEADER; tr '[A-Z]' '[a-z]' <$BODY ) | deliver -n "$1"

       When  Deliver executes a delivery file(1,n), it expects the delivery file(1,n) to
       output a complete list of all addresses and/or  mailboxes  that  should
       receive  the message.  Therefore, if(3,n) a delivery file(1,n) produces no output
       at all, Deliver assumes that there is a  problem.   In  that  case,  to
       avoid  total loss of the message, Deliver saves it in(1,8) the ``undelivered
       mail(1,8)'' mailbox, named(5,8) ``Undel.mail''  in(1,8)  the  home  directory  of  the
       delivery  file(1,n)'s  owner.   For the purpose of undelivered mail(1,8), system,
       post-user and error(8,n) delivery files are considered to be owned by  root.
       Therefore, the postmaster should occasionally check ``/Undel.mail'' for
       mail(1,8) that went undelivered due to errors  in(1,8)  the  systemwide  delivery

       Sometimes  a  delivery  file(1,n)  writer really does want Deliver to drop a
       message.  For example, if(3,n) a delivery file(1,n) stores a message  by  running
       ``deliver -b'', then there's no need for the parent Deliver to save the
       message again.  A delivery file(1,n) can tell Deliver not to save  the  mes-
       sage  by  outputting the string(3,n) ``DROP''.  A delivery file(1,n)'s outputting
       ``DROP'' removes the undelivered mail(1,8)  safety  net  for  that  delivery
       file.  Think of ``DROP'' as shorthand for: ``Trust me.  I know what I'm
       doing.''  If the delivery file(1,n)  outputs  any  addresses  before  and/or
       after ``DROP'', then the ``DROP'' has no effect.

       The  example  delivery  file(1,n)  given  above  never generates any output.
       Therefore, it should always output ``DROP'':

           ( cat $HEADER; tr '[A-Z]' '[a-z]' <$BODY ) | deliver -n "$1"
           echo(1,3x,1 builtins) DROP

       Note that the error(8,n) delivery file(1,n) is an exception to the ``DROP'' rule.
       After  all,  the  error(8,n) delivery file(1,n) never receives valid addresses as
       arguments, so no output is expected (though it is allowed).

       If Deliver is setuid root -- which it should be for normal operation --
       then  the  system,  post-user  and error(8,n) delivery files are executed as
       root.  Be very careful about its permissions and its  contents!   Care-
       lessness here can easily create a security problem.

       All  user  delivery  files  are  executed in(1,8) the context of the user in(1,8)
       whose home directory they reside.  A user's  ``context''  includes  the
       uid, gid, and home directory as specified in(1,8) /etc/passwd.

       For  security  reasons,  if(3,n)  a user's home directory is writable to the
       world, Deliver will ignore any delivery file(1,n) that might be found there.

       For  security  reasons,  no user can request writing a specific mailbox
       under another user's context.  Otherwise, any user could  modify  other
       users(1,5)' private files.

       For  security reasons, Deliver will not write(1,2) to a system mailbox if(3,n) it
       has more than one hard link.

       Deliver records its activity in(1,8) two files: the ``delivery log'',  named(5,8)
       /usr/adm/deliver.log,      and     the     ``error(8,n)     log'',     named(5,8)

       The deliver log is a record of activity of each Deliver process.   Each
       delivery  log entry include the users(1,5) or mailboxes named(5,8) on the command
       line, the users(1,5) and/or mailboxes where delivery  succeeded,  and  those
       where it failed.

       The  error(8,n)  log  is a record of any problems encounted during delivery.
       Each error(8,n) log entry includes all diagnostic output, a copy of the mes-
       sage header, and miscellaneous other information.

       If you want a delivery log, you must create the delivery log file(1,n) your-
       self.  If the delivery log file(1,n) does not exist, Deliver will not create

       If Deliver is performing a ``dry run'' -- that is, if(3,n) the -d (debug) or
       -A (print address) flag is specified -- it will not write(1,2) to either log

       If  the  -v  (verbose) flag is specified, Deliver will not write(1,2) to the
       error(8,n) log.

       Several preprocessor labels may be defined during compilation  to  con-
       trol  the  method(s)  used  by Deliver to lock mailboxes.  These labels

              Lock on exclusive creation of the mailbox  name  with  ``.lock''
              appended.  (Version 7 and early BSD mailers use this method.)

              Lock  on exclusive creation of /tmp/basename.mlk, where basename(1,3,3 File::Basename)
              is the last component of the mailbox pathname.   (Xenix  mailers
              use this method.)

              Exclusively lock mailbox with lockf().

              Exclusively lock mailbox with fcntl().

              Exclusively lock mailbox with locking().

       Neither,  one  or  both  of  ML_DOTLOCK and ML_DOTMLK may be specified.
       None or one of ML_LOCKF, ML_FCNTL or ML_LOCKING may be specified.

       /usr/local/lib/deliver.sys      system delivery file(1,n)
       /usr/local/lib/     post-user delivery file(1,n)
       /usr/local/lib/deliver.err      error(8,n) delivery file(1,n)
       ~user/.deliver                  user delivery file(1,n)(s)
       /usr/adm/deliver.log            delivery log
       /usr/adm/deliver.errlog         error(8,n) log
       /etc/systemid                   system name (Xenix only)

       Please mail(1,8) enhancements, enhancement requests, trouble  reports,  etc.
       to <>.  See also the Debian GNU/Linux bug tracking system

       header(1), mail(1,8)(1), uux(1), smail(8), sendmail(1,8)(8)

                                  Deliver 2.1                       DELIVER(8)

References for this manual (incoming links)