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

FreeBSD Manual Pages

  
 
  

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

NAME
       send - send an nmh message

SYNOPSIS
       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] [-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 user-
	    name] [-tls] [-initialtls] [-notls]	[-certverify] [-nocertverify]
	    [-width columns] [file ...]

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 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.   whatnow(1)  de-
       scribes the user	interface for managing MIME attachments	via this mech-
       anism.

       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.  This method is also used if the configured mimetype-
       proc  fails  to find the	MIME type of the content.  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  pro-
       file,  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 outside of the	ASCII  range.	See  mhshow(1)
       for more	details	and example syntax.

       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
       selected.

       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)  fea-
       ture.  Consult mh-draft(5) for more information.

       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. The body	of  this  new  message
       will  contain a copy of the message sent	to the sighted recipients, ei-
       ther marked up with the indicator text "Blind-Carbon-Copy" or  encapsu-
       lated as	a MIME digest.

       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 exactly  the  same	message	 as  the  sighted  recipients.
       *WARNING* Recipients listed in the "Dcc:" field receive no explicit in-
       dication	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	 acci-
       dent.

       If  the sendmail/pipe mail transport method is used, then messages con-
       taining a "Dcc:"	field are rejected.

       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-
       fect.

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

       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 sendmail/pipe	or sendmail/smtp as its	mail transport
       system, the -sendmail switch can	be used	to override the	default	 send-
       mail 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 mh-profile(5).  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 pro-
       vide to SASL other than the default.  The credentials profile entry  in
       mh-profile(5) 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 post(8)'s	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	 mhlo-
       gin(1) 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	post(8)'s description  of  -snoop  for
       its other features.  The	-notls switch will disable all attempts	to ne-
       gotiate 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:

	    sendfrom-gmail_address@example.com:	-sasl -saslmech	xoauth2
		 -authservice gmail -tls -server smtp.gmail.com
		 -user gmail_login@example.com

       (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
	    sendfrom-sendgrid_address@example.com: -sasl -tls
		 -server smtp.sendgrid.net
	    sendfrom-outbound.att.net: -sasl -initialtls
		 -server outbound.att.net -port	465
	    sendfrom-fastmail.com: -initialtls -sasl -saslmech LOGIN
		 -server smtps-proxy.messagingengine.com -port 80

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

	    machine smtp.sendgrid.net
		 login sendgrid_login@example.com
		 password ********
	    machine outbound.att.net
		 login att_login@example.com
		 password ********
	    machine smtps-proxy.messagingengine.com
		 login fastmail_login@example.com
		 password ********

       For  more information on	authentication to mail servers,	see mhlogin(1)
       for OAuth services, and mh-profile(5) for login credentials.

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

SEE ALSO
       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)

DEFAULTS
       `file' defaults to <mh-dir>/draft
       `-alias'	defaults to /usr/local/etc/nmh/MailAliases
       `-nodraftfolder'
       `-nofilter'
       `-format'
       `-forward'
       `-nomime'
       `-nomsgid'
       `-messageid localname'
       `-nopush'
       `-noverbose'
       `-nowatch'
       `-width 72'
       `-certverify'

CONTEXT
       None

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

nmh-1.7+dev			  2017-05-11			       SEND(1)

NAME | SYNOPSIS | DESCRIPTION | FILES | PROFILE COMPONENTS | SEE ALSO | DEFAULTS | CONTEXT | BUGS

Want to link to this manual page? Use this URL:
<https://www.freebsd.org/cgi/man.cgi?query=send&manpath=FreeBSD+13.1-RELEASE+and+Ports>

home | help