Provided by: nmh_1.3-1_i386 bug

NAME

       post - deliver a message

SYNOPSIS

       /usr/lib/mh/post [-alias aliasfile] [-filter filterfile] [-nofilter]
            [-format | -noformat] [-mime | -nomime] [-msgid | -nomsgid]
            [-verbose | -noverbose] [-watch | -nowatch] [-width columns]
            [-sasl] [-saslmech mechanism] [-user username] file [-version]
            [-help]

DESCRIPTION

       Post  is  the  default program called by send to deliver the message in
       file to local  and  remote  users.   In  fact,  most  of  the  features
       attributed  to send in its manual page are performed by post, with send
       acting as a relatively simple preprocessor.  Thus,  it  is  post  which
       parses  the  various  header fields, appends "From:" and "Date:" lines,
       and interacts with the mail transport system.  Post will  not  normally
       be called directly by the user.

       Post  searches  the  "To:",  "cc:",  "Bcc:",  "Fcc:", and "Resent-xxx:"
       header lines of the specified message for destination addresses, checks
       these  addresses  for  validity,  and  formats them so as to conform to
       ARPAnet Internet Message Format protocol, unless the -noformat flag  is
       set.   This  will  normally  cause "@local-site" to be appended to each
       local destination address, as well as any local return addresses.   The
       -width  columns  switch can be used to indicate the preferred length of
       the header components that contain addresses.

       If a "Bcc:" field is  encountered,  its  addresses  will  be  used  for
       delivery, and the "Bcc:" field will be removed from the message sent to
       sighted recipients.  The blind recipients will receive an entirely  new
       message  with  a  minimal  set of headers.  Included in the body of the
       message will be a copy of the message sent to the  sighted  recipients.
       If  -filter  filterfile  is  specified,  then  this  copy  is  filtered
       (re-formatted) by mhl prior to being  sent  to  the  blind  recipients.
       Alternately,  if the -mime switch is given, then post will use the MIME
       rules for encapsulation.

       The -alias aliasfile switch can be used to specify  a  file  that  post
       should  take  aliases  from.  More than one file can be specified, each
       being preceded with -alias.  In any event, the primary  alias  file  is
       read first.

       The    -msgid    switch    indicates    that    a    "Message-ID:"   or
       "Resent-Message-ID:" field should be added to the header.

       The -verbose switch indicates that the user should be informed of  each
       step of the posting/filing process.

       The  -watch  switch  indicates  that  the  user would like to watch the
       transport system's handling of the  message  (e.g.,  local  and  "fast"
       delivery).

       Under  normal  circumstances,  post  constructs the "From:" line of the
       message from the user's login name, the full name from the GECOS  field
       of  the  passwd file, and the fully-qualified name of the local machine
       (or the value of "localname" in  mts.conf,  if  set).   An  example  is
       "From: Dan Harkless <dan@machine.company.com>".  There are four ways to
       override these values,  however.   Note  that  they  apply  equally  to
       "Resent-From:" lines in messages sent with dist.

       The   first   way   is   GECOS-based  username  masquerading.   If  the
       "masquerade:" line in mts.conf contains "mmailid", this  processing  is
       activated.   If  a user's GECOS field in the passwd file is of the form
       "Full Name <fakename>" then "fakename" will be used  in  place  of  the
       real   username.    For  instance,  a  GECOS  field  of  "Dan  Harkless
       <Dan.Harkless>"    would    result    in    "From:     Dan     Harkless
       <Dan.Harkless@machine.company.com>".    Naturally  if  you  were  doing
       something like this you'd  want  to  set  up  an  MTA  alias  (e.g.  in
       /etc/aliases) from, for instance, "Dan.Harkless" to "dan".

       The  second  way  to override default construction of "From:" is to set
       the $SIGNATURE environment variable.  This variable overrides the  full
       name  from  the  GECOS field, even if GECOS-based masquerading is being
       done.  This processing is always  active,  and  does  not  need  to  be
       enabled from mts.conf.

       The   third   way  is  controlled  by  the  "user_extension"  value  of
       "masquerade:" line of mts.conf.  When that's  turned  on,  setting  the
       $USERNAME_EXTENSION environment variable will result in its value being
       appended  the  user's   login   name.    For   instance,   if   I   set
       $USERNAME_EXTENSION  to  "+www",  my  "From:"  line  will  contain "Dan
       Harkless <dan+www@machine.company.com>" (or "Dan.Harkless+www"  if  I'm
       using  mmailid  masquerading  as  well).   Recent  versions of sendmail
       automatically deliver all mail sent to user+string to user.  qmail  has
       a  similar  feature which uses '-' as the delimiter by default, but can
       use other characters as well.

       The fourth method of address masquerading is to specify a "From:"  line
       manually  in  the  message  draft.   It will be used as provided (after
       alias substitution), but normally, to  discourage  email  forgery,  the
       user's  real address will be used in the SMTP envelope "From:" and in a
       "Sender:" header.  However,  if  the  "masquerade:"  line  of  mts.conf
       contains  "draft_from",  the SMTP envelope "From:" will use the address
       given in the draft "From:", and there  will  be  no  "Sender:"  header.
       This is useful in pretending to send mail "directly" from a remote POP3
       account, or when remote email robots give improper  precedence  to  the
       envelope  "From:".   Note  that  your  MTA  may  still reveal your real
       identity (e.g.  sendmail's "X-Authentication-Warning:" header).

       If nmh has been compiled with  SASL  support,  the  -sasl  switch  will
       enable  the use of SASL authentication with the SMTP MTA.  Depending on
       the SASL mechanism used, this may require an additional password prompt
       from  the  user  (but  the  ".netrc"  file  can  be  used to store this
       password).  -saslmech switch can be used to select  a  particular  SASL
       mechanism,   and  the  the  -user  switch  can  be  used  to  select  a
       authorization userid to provide to SASL other than the default.

       Currently SASL security layers are not supported for SMTP.  nmh's  SMTP
       SASL  code will always negotiate an unencrypted connection.  This means
       that while the SMTP authentication can  be  encrypted,  the  subsequent
       data  stream  can not.  This is in contrast to nmh's POP3 SASL support,
       where encryption is supported for both the authentication and the  data
       stream.

FILES

       /etc/nmh/mts.conf          nmh mts configuration file
       /etc/nmh/MailAliases       global nmh alias file
       /usr/bin/mh/refile         Program to process Fcc:s
       /usr/lib/mh/mhl            Program to process Bcc:s

PROFILE COMPONENTS

       post does NOT consult the user's .mh_profile

SEE ALSO

       mhmail(1), send(1), mh-mail(5), mh-alias(5), mh-tailor(5), Standard for
       the Format of ARPA Internet Text Messages (RFC-822)

DEFAULTS

       `-alias' defaults to /etc/nmh/MailAliases
       `-format'
       `-nomime'
       `-nomsgid'
       `-noverbose'
       `-nowatch'
       `-width 72'
       `-nofilter'

CONTEXT

       None

BUGS

       "Reply-To:" fields are allowed to have groups in them according to  the
       822 specification, but post won't let you use them.