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

FreeBSD Manual Pages


home | help
SEND(1)								       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