Provided by: nmh_1.3-1_i386 bug

NAME

       send - send a message

SYNOPSIS

       send [-alias aliasfile] [-draft] [-draftfolder +folder] [-draftmessage
            msg] [-nodraftfolder] [-filter filterfile] [-nofilter] [-format |
            -noformat] [-forward | -noforward] [-mime | -nomime] [-msgid |
            -nomsgid] [-push | -nopush] [-split seconds] [-verbose |
            -noverbose] [-watch | -nowatch] [-sasl] [-saslmech mechanism]
            [-user username] [-width columns] [file ...]  [-version] [-help]
            [-attach header-field-name] [-attachformat 0 | 1 | 2]

DESCRIPTION

       Send  will cause each of the specified files to be delivered to each of
       the destinations in the “To:”, “cc:”, “Bcc:”, “Dcc:”, and “Fcc:” fields
       of  the message.  If send is re-distributing a message, as invoked from
       dist, then the corresponding “Resent-xxx” fields are examined  instead.

       By default, send uses the program post to do the actual delivery of the
       messages, although this can be changed by defining the postproc profile
       component.   Most  of  the  features  attributed  to  send are actually
       performed by post.

       If a header-field-name is supplied using the -attach option, the  draft
       is  scanned  for a header whose field name matches the supplied header-
       field-name.  The draft is converted to a MIME message if  one  or  more
       matches are found.  This conversion occurs before all other processing.

       The first part of the MIME message is  the  draft  body  if  that  body
       contains any non-blank characters.  The body of each header field whose
       name matches the header-field-name is interpreted as a file  name,  and
       each file named is included as a separate part in the MIME message.

       For  file names with dot suffixes, the context is scanned for a mhshow-
       suffix- entry for that suffix.  The content-type for the part is  taken
       from  that  context entry if a match is found.  If no match is found or
       the file does not have a dot suffix, the content-type is text/plain  if
       the  file contains only ASCII characters or application/octet-stream if
       it contains characters outside of the ASCII range.

       Each part contains a name attribute that is the last component  of  the
       path   name.    A   x-unix-mode  attribute  containing  the  file  mode
       accompanies each part.  Finally, a description attribute  is  generated
       by running the file command on the file.

       The  -attachformat  option  specifies the MIME header field formats:  a
       value of 0, the default, includes the x-unix-mode  attribute  as  noted
       above.  A value of 1 suppresses both that and the “Content-Description”
       header, and adds a “Content-Disposition” header.  A value of 2 adds the
       file  modification-date  parameter to the “Content-Disposition” header.
       You can specify  one  value  in  your  profile,  and  override  it  for
       individual messages at the whatnow prompt.

       Here  are  example  message  part headers for each of the -attachformat
       values:

       -attachformat 0:
       Content-Type: text/plain; name="VERSION"; x-unix-mode="0644";
            charset="us-ascii"
       Content-Description: ASCII text

       -attachformat 1:
       Content-Type: text/plain; charset="us-ascii"
       Content-Disposition: attachment; filename="VERSION"

       -attachformat 2:
       Content-Type: text/plain; charset="us-ascii"
       Content-Disposition: attachment; filename="VERSION"; modification-date="Mon, 19 Dec 2005 22:39:51 -0600"

       If -push is specified, send will detach itself from the user’s terminal
       and  perform  its  actions  in the background.  If push’d and the draft
       can’t be sent, then an error message will be sent (using the  mailproc)
       back  to the user.  If -forward is given, then a copy of the draft will
       be attached to this failure notice.  Using -push differs  from  putting
       send  in  the  background because the output is trapped and analyzed by
       nmh.

       If -verbose is specified, send will indicate the interactions occurring
       with  the  transport  system,  prior  to actual delivery.  If -watch is
       specified send will monitor the delivery of  local  and  network  mail.
       Hence,  by  specifying both switches, a large detail of information can
       be gathered about each step of the message’s entry into  the  transport
       system.

       The  -draftfolder +folder and -draftmessage msg switches invoke the nmh
       draft folder  facility.   This  is  an  advanced  (and  highly  useful)
       feature.  Consult the mh-draft(5) man page for more information.

       If  -split  is  specified,  send  will split the draft into one or more
       partial messages prior to sending.  This makes use of the MIME features
       in  nmh.   Note  however  that if send is invoked under dist, then this
       switch is ignored -- it makes no sense to  redistribute  a  message  in
       this fashion.  Sometimes you want send to pause after posting a partial
       message.  This is usually the case when you are  running  sendmail  and
       expect  to  generate a lot of partial messages.  The argument to -split
       tells it how long to pause between postings.

       Send with no file argument will query whether the draft is the intended
       file,  whereas  -draft will suppress this question.  Once the transport
       system has successfully accepted custody of the message, the file  will
       be  renamed with a leading comma, which allows it to be retrieved until
       the next draft message is sent.  If there are errors in the  formatting
       of  the  message,  send  will  abort  with  a (hopefully) helpful error
       message.

       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 a “Dcc:” field is  encountered,  its  addresses  will  be  used  for
       delivery,  and  the “Dcc:” field will be removed from the message.  The
       blind recipients will receive the same  message  sent  to  the  sighted
       recipients.  *WARNING* Recipients listed in the “Dcc:” field receive no
       explicit indication that they have received a “blind copy”.   This  can
       cause  blind  recipients  to  inadvertently reply to all of the sighted
       recipients of the original message,  revealing  that  they  received  a
       blind  copy.  On the other hand, since a normal reply to a message sent
       via a “Bcc:” field will generate a reply only  to  the  sender  of  the
       original message, it takes extra effort in most mailers to reply to the
       included message, and so  would  usually  only  be  done  deliberately,
       rather than by accident.

       If  -filter  filterfile  is  specified,  then  this  copy  is  filtered
       (re-formatted) by mhl prior to being  sent  to  the  blind  recipients.
       Alternately,  if  you  specify the -mime switch, then send will use the
       MIME rules for encapsulation.

       Prior to  sending  the  message,  the  fields  “From: user@local”,  and
       “Date: now”  will  be  appended  to the headers in the message.  If the
       environment variable $SIGNATURE is set, then its value is used as  your
       personal  name  when  constructing the “From:” line of the message.  If
       this environment variable is  not  set,  then  send  will  consult  the
       profile   entry   “Signature”  for  this  information.   If  -msgid  is
       specified, then a  “Message-ID:”  field  will  also  be  added  to  the
       message.

       If  send  is  re-distributing  a  message  (when invoked by dist), then
       “Resent-” will be prepended to each of these fields: “From:”,  “Date:”,
       and  “Message-ID:”.   If  the message already contains a “From:” field,
       then a “Sender: user@local” field will be added as well.   (An  already
       existing “Sender:” field is an error!)

       By using the -format switch, each of the entries in the “To:” and “cc:”
       fields will be replaced with “standard” format entries.  This  standard
       format  is  designed to be usable by all of the message handlers on the
       various systems around the  Internet.   If  -noformat  is  given,  then
       headers are output exactly as they appear in the message draft.

       If  an  “Fcc: folder” is encountered, the message will be copied to the
       specified folder for the sender in the format in which it  will  appear
       to  any  non-Bcc  receivers  of the message.  That is, it will have the
       appended fields and field reformatting.   The  “Fcc:”  fields  will  be
       removed from all outgoing copies of the message.

       By  using the -width columns switch, the user can direct send as to how
       long it should make header lines containing addresses.

       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.

       The   files  specified  by  the  profile  entry  “Aliasfile:”  and  any
       additional alias files given by the -alias  aliasfile  switch  will  be
       read  (more than one file, each preceded by -alias, can be named).  See
       mh-alias(5) for more information.

FILES

       $HOME/.mh_profile          The user profile

PROFILE COMPONENTS

       Path:                To determine the user’s nmh directory
       Draft-Folder:        To find the default draft-folder
       Aliasfile:           For a default alias file
       Signature:           To determine the user’s mail signature
       mailproc:            Program to post failure notices
       postproc:            Program to post the message

SEE ALSO

       comp(1), dist(1), forw(1), repl(1), mh-alias(5), post(8)

DEFAULTS

file’ defaults to <mh-dir>/draft
       ‘-alias’ defaults to /etc/nmh/MailAliases
       ‘-nodraftfolder’
       ‘-nofilter’
       ‘-format’
       ‘-forward’
       ‘-nomime’
       ‘-nomsgid’
       ‘-nopush’
       ‘-noverbose’
       ‘-nowatch’
       ‘-width 72’
       ‘-attachformat 0

CONTEXT

       None

BUGS

       Under some configurations, it is  not  possible  to  monitor  the  mail
       delivery transaction; -watch is a no-op on those systems.

       Using -split 0 doesn’t work correctly.