Provided by: nmh_1.3-1build1_amd64 bug


       post - deliver a message


       /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]


       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

       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 <>”.  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 <>”.  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
       <>” (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


       /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


       post does NOT consult the user's .mh_profile


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


       `-alias' defaults to /etc/nmh/MailAliases
       `-width 72'




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