Skip site navigation (1)Skip section navigation (2)

FreeBSD Manual Pages


home | help
SEND(1)			    General Commands Manual		       SEND(1)

       send - send a message

       send [-alias aliasfile] [-draft]	[-draftfolder +folder] [-draftmessage
	    msg] [-nodraftfolder] [-filter filterfile] [-nofilter] [-format |
	    -noformat] [-forward | -noforward] [-mime |	-nomime] [-msgid |
	    -nomsgid] [-messageid localname | random] [-push | -nopush]
	    [-split seconds] [-verbose | -noverbose] [-watch | -nowatch] [-mts
	    smtp | sendmail/smtp | sendmail/pipe] [-server servername] [-port
	    port-name/number] [-sasl] [-nosasl]	[-saslmaxssf ssf] [-saslmech
	    mechanism] [-snoop]	[-user username] [-tls]	[-initialtls] [-notls]
	    [-width columns] [file ...]	 [-version] [-help]

       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  per-
       formed by post.

       Before send gives the message to	post for delivery, the message is pro-
       cessed by mhbuild to perform any	necessary MIME encoding	of the	outgo-
       ing  message.   This can	be changed by the buildmimeproc	profile	compo-
       nent.  mhbuild is invoked with the -auto	switch,	so mhbuild  directives
       are not processed by default.  See mhbuild(1) for more information.

       mhbuild	will  scan  the	 message draft for a header named Attach.  The
       draft is	converted to a MIME message if one or more matches are	found.
       This conversion occurs before all other processing.  The	whatnow(1) man
       page describes the user interface for  managing	MIME  attachments  via
       this mechanism.

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

       Determination of	the content MIME type inserted into  the  Content-Type
       header  for  each  part depends on how the nmh installation was config-
       ured.  If a program, such as file with a	--mime or -i option, was found
       that  can  specify  the type of a file as a MIME	type string, then that
       will be used.  To determine if your nmh was so configured, run  mhparam
       mimetypeproc and	see if a non-empty string is displayed.

       If your nmh was not configured with a program to	specify	a file type as
       a MIME string, then a different method is used to  determine  the  con-
       tent-type  string.   For	 file  names with dot suffixes,	the profile is
       scanned for a mhshow-suffix- entry for that suffix.   The  content-type
       for  the	part is	taken from that	profile	entry if a match is found.  If
       a match is not found in the user	profile, the mhn.defaults  profile  is
       scanned	next.	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 out-
       side of the ASCII range.	 See mhshow(1) for more	 details  and  example

       Each  attached  MIME  part contains a "Content-Description" header that
       includes	the filename, and adds a "Content-Disposition"	header.	  Here
       is an example of	MIME part headers for an attachment:

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

       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

       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

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

       If -split is specified, send will split the draft into one or more par-
       tial 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 fash-
       ion.  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 site-dependent	prefix (usually	a 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	(hope-
       fully) helpful error message.

       If a "Bcc:" field is encountered, its addresses will be used for	deliv-
       ery, 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 and the sendmail/pipe	mail transport
       method is not in	use, 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  recipi-
       ents  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	 acci-

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

       Prior to	sending	the message, the "Date:	now" field will	be appended to
       the  headers  in	 the  message.	 If  -msgid is specified, then a "Mes-
       sage-ID:" field will also be added to the message.

       The -messageid switch selects the style used  for  the  part  appearing
       after  the  @ in	"Message-ID:", "Resent-Message-ID:", and "Content-ID:"
       header fields.  The two acceptable options are localname	(which is  the
       default),  and  random.	 With  localname,  the local hostname is used.
       With random, a random sequence of characters  is	 used  instead.	  Note
       that  the  -msgid  switch  must	be enabled for this switch to have any

       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:".

       A "From:" field	is  required  for  all	outgoing  messages.   Multiple
       addresses  are permitted	in the "From:" field, but a "Sender:" field is
       required	in this	case.  Otherwise a "Sender:" field is optional.

       If a message  with  multiple  "From:"  addresses	 does  NOT  include  a
       "Sender:"  field	but does include an "Envelope-From:" field, the	"Enve-
       lope-From:" field will be used to construct a "Sender:" field.

       When using SMTP for mail	submission, the	 envelope-from	used  for  the
       SMTP  transaction  is  derived  from the	"Envelope-From:" field.	 If no
       "Envelope-From:"	field is present, the "Sender:"	 field	is  used.   If
       neither	the  "Envelope-From:"  nor the "Sender:" field is present, the
       "From:" field is	used.  When "Envelope-From:" appears in	a  message  it
       will be removed from the	final outgoing message.

       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 head-
       ers 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.

       The    mail    transport	   system    default	is     provided	    in
       /usr/local/etc/nmh/mts.conf  but	 can  be overriiden here with the -mts

       If nmh is using the SMTP	MTA, the -server and the -port switches	can be
       used   to   override   the   default   mail   server  (defined  by  the
       /usr/local/etc/nmh/mts.conf servers entry).  The	-snoop switch  can  be
       used  to	 view the SMTP transaction.  (Beware that the SMTP transaction
       may contain authentication information either in	 plaintext  or	easily
       decoded base64.)

       If  nmh	has  been  compiled  with  SASL	support, the -sasl and -nosasl
       switches	will enable and	disable	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,	 as described in the mh-profile(5) man
       page).  The -saslmech switch can	be used	to select  a  particular  SASL
       mechanism,  and	the -user switch can be	used to	select a authorization
       userid to provide to SASL other than the	default.  The credentials pro-
       file entry in the mh-profile(5) man page	describes the ways to supply a
       username	and password.

       If SASL authentication is successful, nmh will attempt to  negotiate  a
       security	layer for session encryption.  Encrypted data is labelled with
       `(encrypted)' and `(decrypted)' when viewing the	SMTP transaction  with
       the  -snoop  switch.   The -saslmaxssf switch can be used to select the
       maximum value of	the Security Strength  Factor.	 This  is  an  integer
       value  and  the	exact  meaning of this value depends on	the underlying
       SASL mechanism.	A value	of 0 disables encryption.

       If nmh has been compiled	with TLS support,  the	-tls  and  -initialtls
       switches	 will  require	the  negotiation of TLS	when connecting	to the
       SMTP MTA.  The -tls switch will negotiate TLS as	 part  of  the	normal
       SMTP protocol using the STARTTLS	command.  The -initialtls will negoti-
       ate TLS immediately after the connection	has taken  place,  before  any
       SMTP  commands  are  sent or received.  Encrypted data is labelled with
       `(tls-encrypted)' and `(tls-decrypted)' when viewing the	 SMTP  transc-
       tion  with  the	-snoop	switch.	  The  -notls  switch will disable all
       attempts	to negotiate TLS.

       The files specified by the profile entry	 "Aliasfile:"  and  any	 addi-
       tional  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.

       $HOME/.mh_profile		    The	user profile

       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

       comp(1),	 dist(1),  file(1),  forw(1), mhparam(1), repl(1), whatnow(1),
       mh-alias(5), mh-profile(5), mh-tailor(5), post(8)

       `file' defaults to <mh-dir>/draft
       `-alias'	defaults to /usr/local/etc/nmh/MailAliases
       `-messageid localname'
       `-width 72'


       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.

nmh-1.6			       January 23, 2014			       SEND(1)


Want to link to this manual page? Use this URL:

home | help