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 af-
       ter  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 ef-

       If send is re-distributing a message (when invoked by dist), then  "Re-
       sent-" will be prepended	to each	of these fields: "From:", "Date:", and

       A "From:" field is required for all outgoing  messages.	 Multiple  ad-
       dresses	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 ap-
       pended fields and field reformatting.  The "Fcc:" fields	 will  be  re-
       moved 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/lo-
       cal/etc/nmh/mts.conf but	can be overriiden here with the	-mts switch.

       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/lo-
       cal/etc/nmh/mts.conf  servers entry).  The -snoop switch	can be used to
       view the	SMTP transaction.  (Beware that	the SMTP transaction may  con-
       tain  authentication  information either	in plaintext or	easily decoded

       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  at-
       tempts 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 de-
       livery 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