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

FreeBSD Manual Pages


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

       send - send an nmh message

       send [-help] [-version] [-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] [-sendmail
	    program] [-server servername] [-port port-name/number] [-sasl]
	    [-nosasl] [-saslmech mechanism] [-authservice service] [-snoop]
	    [-user username] [-tls] [-initialtls] [-notls] [-certverify] [-no-
	    certverify]	[-width	columns] [file ...]

       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"

       See mhbuild(1) for explanation of how the Content-Disposition value  is

       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.	*WARN-
       ING*  Recipients	listed in the "Dcc:" field receive no explicit indica-
       tion that they have received a "blind copy".  This can cause blind  re-
       cipients	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.

       Beware  that  if	an "Fcc:" with one or more folders is present but none
       of the folders exist, and the default fileproc and postproc are in use,
       then  refile  will  prompt the user to create the folder(s) if -push is
       not specified.  If all responses	are  negative,	or  creation  of  each
       folder  fails, or -push is specified, the message will not be copied to
       any folder and will be  removed	by  post.   With  the  default	refile
       switches, the message draft will	be renamed according to	the specifica-
       tion of its -nolink switch.

       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 overridden here with the	-mts switch.

       If nmh is using as its mail transport system sendmail/pipe, the	-send-
       mail switch can be used to override the default sendmail	program.

       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
       base64.)	 If -sasl -saslmech xoauth2 is used, the HTTP  transaction  is
       also shown.

       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; see the post	man page description of	-snoop for its
       other features.

       If nmh has been compiled	with OAuth support, the	 -sasl	and  -saslmech
       xoauth2	switches  will	enable OAuth authentication.  The -user	switch
       must be used, and the username must be an email address	the  user  has
       for  the	service, which must be specified with the -authservice service
       switch.	Before using OAuth authentication, the user must authorize nmh
       by  running  mhlogin  and grant authorization to	that account.  See the
       mhlogin(1) man page for more details.

       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  transac-
       tion  with  the	-snoop	switch;	 see  the post man page	description of
       -snoop for its other features.  The -notls switch will disable all  at-
       tempts to negotiate TLS.

       If  port	 465  is  specified and	none of	the TLS	switches were enabled,
       -initialtls will	be implied if TLS support  was	compiled  in.	Though
       port 465	for SMTPS (SMTP	over SSL) was deregistered by IANA in 1998, it
       is still	used for that service.

       When using TLS the default is to	verify the remote certificate and Sub-
       jectName	against	the local trusted certificate store.  This can be con-
       trolled by  the	-certverify  and  -nocertverify	 switches.   See  your
       OpenSSL documentation for more information on certificate verification.

       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.

   Selection based on sender address: sendfrom
       One or more sendfrom profile components can be used to  select  a  mail
       server  address,	mail server port, or any other switch that can be sup-
       plied to	post.  It works	by first looking at the	sender address and do-
       main  name in the message draft,	as described below.  It	then looks for
       a corresponding profile entry, which contains the  post	switches.   To
       enable, add profile entries of the form:

	    sendfrom-address/domain name: post switches

       The  email address is extracted from the	Envelope-From:	header,	if not
       blank, the Sender: header, or the From:	header	line  in  the  message
       draft.  Multiple	profile	entries, with different	email addresses	or do-
       main names, are supported.  This	allows	different  switches  to	 post,
       such  as	 -user,	to be associated with different	email addresses.  If a
       domain name is used, it matches all users in that domain.

       Here is an example profile entry	using OAuth for	an account  hosted  by
       gmail:	-sasl -saslmech	xoauth2
		 -authservice gmail -tls -server

       (Indentation  indicates a continued line, as supported in MH profiles.)
       The username need not be	the same as the	sender address,	which was  ex-
       tracted from the	appropriate header line	as noted above.

       Here are	example	profile	entries	that use an nmh	credentials file:

	    credentials: file:nmhcreds -sasl -tls
		 -server -sasl -initialtls
		 -server -port	465 -initialtls -sasl -saslmech LOGIN
		 -server -port 80

       where  nmhcreds	is  in the user's nmh directory	(from the Path profile
       component) and contains:

		 password ********
		 password ********
		 password ********

       For more	information on authentication to mail servers, see  the	 mhlo-
       gin(1)  man page	for OAuth services, and	mh-profile(5) man page for lo-
       gin credentials.

       $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
       sendfrom-address:    Switches to	post for sender	address
       sendfrom-domain:	    Switches to	post for sender	domain name

       comp(1),	dist(1), file(1), forw(1), mhbuild(1), mhparam(1), mhlogin(1),
       refile(1),  repl(1),  whatnow(1),  mh-alias(5),	mh-profile(5), mh-tai-
       lor(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.7.1			  2017-05-11			       SEND(1)


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

home | help