1SEND(1)                     General Commands Manual                    SEND(1)
2
3
4

NAME

6       send - send an nmh message
7

SYNOPSIS

9       send [-help] [-version] [-alias aliasfile] [-draft] [-draftfolder
10            +folder] [-draftmessage msg] [-nodraftfolder] [-filter filterfile]
11            [-nofilter] [-format | -noformat] [-forward | -noforward] [-mime |
12            -nomime] [-msgid | -nomsgid] [-messageid localname | random]
13            [-push | -nopush] [-split seconds] [-verbose | -noverbose] [-watch
14            | -nowatch] [-mts smtp | sendmail/smtp | sendmail/pipe] [-sendmail
15            program] [-server servername] [-port port-name/number] [-sasl]
16            [-nosasl] [-saslmech mechanism] [-authservice service] [-snoop]
17            [-user username] [-tls] [-initialtls] [-notls] [-certverify]
18            [-nocertverify] [-width columns] [file ...]
19

DESCRIPTION

21       send will cause each of the specified files to be delivered to each  of
22       the destinations in the “To:”, “cc:”, “Bcc:”, “Dcc:”, and “Fcc:” fields
23       of the message.  If send is re-distributing a message, as invoked  from
24       dist, then the corresponding “Resent-xxx” fields are examined instead.
25
26       By default, send uses the program post to do the actual delivery of the
27       messages, although this can be changed by defining the postproc profile
28       component.   Most  of the features attributed to send are actually per‐
29       formed by post.
30
31       Before send gives the message to post for delivery, the message is pro‐
32       cessed  by mhbuild to perform any necessary MIME encoding of the outgo‐
33       ing message.  This can be changed by the buildmimeproc  profile  compo‐
34       nent.   mhbuild is invoked with the -auto switch, so mhbuild directives
35       are not processed by default.  See mhbuild(1) for more information.
36
37       mhbuild will scan the message draft for a  header  named  Attach.   The
38       draft  is converted to a MIME message if one or more matches are found.
39       This conversion occurs before all other processing.  The whatnow(1) man
40       page  describes  the  user  interface for managing MIME attachments via
41       this mechanism.
42
43       The first part of the MIME message is the draft body if that body  con‐
44       tains  any  non-blank characters.  The body of each Attach header field
45       is interpreted as a file name, and each file named  is  included  as  a
46       separate part in the MIME message.
47
48       Determination  of  the content MIME type inserted into the Content-Type
49       header for each part depends on how the nmh  installation  was  config‐
50       ured.  If a program, such as file with a --mime or -i option, was found
51       that can specify the type of a file as a MIME type  string,  then  that
52       will  be used.  To determine if your nmh was so configured, run mhparam
53       mimetypeproc and see if a non-empty string is displayed.
54
55       If your nmh was not configured with a program to specify a file type as
56       a  MIME  string,  then a different method is used to determine the con‐
57       tent-type string.  For file names with dot  suffixes,  the  profile  is
58       scanned  for  a mhshow-suffix- entry for that suffix.  The content-type
59       for the part is taken from that profile entry if a match is found.   If
60       a  match  is not found in the user profile, the mhn.defaults profile is
61       scanned next.  If no match is found or the file does  not  have  a  dot
62       suffix,  the content-type is text/plain if the file contains only ASCII
63       characters or application/octet-stream if it contains  characters  out‐
64       side  of  the  ASCII range.  See mhshow(1) for more details and example
65       syntax.
66
67       Each attached MIME part contains a  “Content-Description”  header  that
68       includes  the  filename, and adds a “Content-Disposition” header.  Here
69       is an example of MIME part headers for an attachment:
70
71       Content-Type: text/plain; name="VERSION"; charset="us-ascii"
72       Content-Description: VERSION
73       Content-Disposition: attachment; filename="VERSION"
74
75       See mhbuild(1) for explanation of how the Content-Disposition value  is
76       selected.
77
78       If -push is specified, send will detach itself from the user's terminal
79       and perform its actions in the background.  If  push'd  and  the  draft
80       can't  be sent, then an error message will be sent (using the mailproc)
81       back to the user.  If -forward is given, then a copy of the draft  will
82       be  attached  to this failure notice.  Using -push differs from putting
83       send in the background because the output is trapped  and  analyzed  by
84       nmh.
85
86       If -verbose is specified, send will indicate the interactions occurring
87       with the transport system, prior to  actual  delivery.   If  -watch  is
88       specified  send  will  monitor  the delivery of local and network mail.
89       Hence, by specifying both switches, a large detail of  information  can
90       be  gathered  about each step of the message's entry into the transport
91       system.
92
93       The -draftfolder +folder and -draftmessage msg switches invoke the  nmh
94       draft  folder  facility.   This is an advanced (and highly useful) fea‐
95       ture.  Consult the mh-draft(5) man page for more information.
96
97       If -split is specified, send will split the draft into one or more par‐
98       tial messages prior to sending.  This makes use of the MIME features in
99       nmh.  Note however that if send is invoked under dist, then this switch
100       is ignored -- it makes no sense to redistribute a message in this fash‐
101       ion.  Sometimes you want send to pause after posting a partial message.
102       This  is  usually  the case when you are running sendmail and expect to
103       generate a lot of partial messages.  The argument to  -split  tells  it
104       how long to pause between postings.
105
106       send with no file argument will query whether the draft is the intended
107       file, whereas -draft will suppress this question.  Once  the  transport
108       system  has successfully accepted custody of the message, the file will
109       be renamed with a site-dependent prefix (usually a comma), which allows
110       it  to be retrieved until the next draft message is sent.  If there are
111       errors in the formatting of the message, send will abort with a  (hope‐
112       fully) helpful error message.
113
114       If a “Bcc:” field is encountered, its addresses will be used for deliv‐
115       ery, and the “Bcc:” field will be removed  from  the  message  sent  to
116       sighted  recipients.  The blind recipients will receive an entirely new
117       message with a minimal set of headers.  Included in  the  body  of  the
118       message will be a copy of the message sent to the sighted recipients.
119
120       If  a  “Dcc:” field is encountered and the sendmail/pipe mail transport
121       method is not in use, its addresses will be used for delivery, and  the
122       “Dcc:”  field  will  be removed from the message.  The blind recipients
123       will receive the same message sent to the sighted  recipients.   *WARN‐
124       ING*  Recipients listed in the “Dcc:” field receive no explicit indica‐
125       tion that they have received a “blind  copy”.   This  can  cause  blind
126       recipients  to  inadvertently reply to all of the sighted recipients of
127       the original message, revealing that they received a  blind  copy.   On
128       the  other  hand,  since  a normal reply to a message sent via a “Bcc:”
129       field will generate a reply only to the sender of the original message,
130       it takes extra effort in most mailers to reply to the included message,
131       and so would usually only be done deliberately, rather  than  by  acci‐
132       dent.
133
134       If -filter filterfile is specified, then this copy is filtered (re-for‐
135       matted) by mhl prior to being sent to  the  blind  recipients.   Alter‐
136       nately,  if  you  specify the -mime switch, then send will use the MIME
137       rules for encapsulation.
138
139       Prior to sending the message, the “Date: now” field will be appended to
140       the  headers  in  the  message.   If  -msgid is specified, then a “Mes‐
141       sage-ID:” field will also be added to the message.
142
143       The -messageid switch selects the style used  for  the  part  appearing
144       after  the  @ in “Message-ID:”, “Resent-Message-ID:”, and “Content-ID:”
145       header fields.  The two acceptable options are localname (which is  the
146       default),  and  random.   With  localname,  the local hostname is used.
147       With random, a random sequence of characters  is  used  instead.   Note
148       that  the  -msgid  switch  must  be enabled for this switch to have any
149       effect.
150
151       If send is re-distributing a  message  (when  invoked  by  dist),  then
152       “Resent-”  will be prepended to each of these fields: “From:”, “Date:”,
153       and “Message-ID:”.
154
155       A “From:” field  is  required  for  all  outgoing  messages.   Multiple
156       addresses  are permitted in the “From:” field, but a “Sender:” field is
157       required in this case.  Otherwise a “Sender:” field is optional.
158
159       If a message  with  multiple  “From:”  addresses  does  not  include  a
160       “Sender:”  field but does include an “Envelope-From:” field, the “Enve‐
161       lope-From:” field will be used to construct a “Sender:” field.
162
163       When using SMTP for mail submission, the  envelope-from  used  for  the
164       SMTP  transaction  is  derived  from the “Envelope-From:” field.  If no
165       “Envelope-From:” field is present, the “Sender:”  field  is  used.   If
166       neither  the  “Envelope-From:”  nor the “Sender:” field is present, the
167       “From:” field is used.  When “Envelope-From:” appears in a  message  it
168       will be removed from the final outgoing message.
169
170       By using the -format switch, each of the entries in the “To:” and “cc:”
171       fields will be replaced with “standard” format entries.  This  standard
172       format  is  designed to be usable by all of the message handlers on the
173       various systems around the Internet.  If -noformat is given, then head‐
174       ers are output exactly as they appear in the message draft.
175
176       If  an  “Fcc: folder” is encountered, the message will be copied to the
177       specified folder for the sender in the format in which it  will  appear
178       to  any  non-Bcc  receivers  of the message.  That is, it will have the
179       appended fields and field reformatting.   The  “Fcc:”  fields  will  be
180       removed from all outgoing copies of the message.
181
182       Beware  that  if an “Fcc:” with one or more folders is present but none
183       of the folders exist, and the default fileproc and postproc are in use,
184       then  refile  will  prompt the user to create the folder(s) if -push is
185       not specified.  If all responses are  negative,  or  creation  of  each
186       folder  fails, or -push is specified, the message will not be copied to
187       any folder and will be  removed  by  post.   With  the  default  refile
188       switches, the message draft will be renamed according to the specifica‐
189       tion of its -nolink switch.
190
191       By using the -width columns switch, the user can direct send as to  how
192       long it should make header lines containing addresses.
193
194       The  mail transport system default is provided in /etc/nmh/mts.conf but
195       can be overridden here with the -mts switch.
196
197       If nmh is using as its mail transport system sendmail/pipe, the  -send‐
198       mail switch can be used to override the default sendmail program.
199
200       If nmh is using the SMTP MTA, the -server and the -port switches can be
201       used  to  override  the   default   mail   server   (defined   by   the
202       /etc/nmh/mts.conf  servers  entry).   The  -snoop switch can be used to
203       view the SMTP transaction.  (Beware that the SMTP transaction may  con‐
204       tain  authentication  information either in plaintext or easily decoded
205       base64.)  If -sasl -saslmech xoauth2 is used, the HTTP  transaction  is
206       also shown.
207
208       If  nmh  has  been  compiled  with  SASL support, the -sasl and -nosasl
209       switches will enable and disable the use of  SASL  authentication  with
210       the  SMTP  MTA.  Depending on the SASL mechanism used, this may require
211       an additional password prompt from the user (but the netrc file can  be
212       used  to  store  this  password,  as described in the mh-profile(5) man
213       page).  The -saslmech switch can be used to select  a  particular  SASL
214       mechanism,  and  the -user switch can be used to select a authorization
215       userid to provide to SASL other than the default.  The credentials pro‐
216       file entry in the mh-profile(5) man page describes the ways to supply a
217       username and password.
218
219       If SASL authentication is successful, nmh will attempt to  negotiate  a
220       security layer for session encryption.  Encrypted data is labelled with
221       `(encrypted)' and `(decrypted)' when viewing the SMTP transaction  with
222       the  -snoop switch; see the post man page description of -snoop for its
223       other features.
224
225       If nmh has been compiled with OAuth support, the  -sasl  and  -saslmech
226       xoauth2  switches  will  enable OAuth authentication.  The -user switch
227       must be used, and the username must be an email address  the  user  has
228       for  the service, which must be specified with the -authservice service
229       switch.  Before using OAuth authentication, the user must authorize nmh
230       by  running  mhlogin  and grant authorization to that account.  See the
231       mhlogin(1) man page for more details.
232
233       If nmh has been compiled with TLS support,  the  -tls  and  -initialtls
234       switches  will  require  the  negotiation of TLS when connecting to the
235       SMTP MTA.  The -tls switch will negotiate TLS as  part  of  the  normal
236       SMTP protocol using the STARTTLS command.  The -initialtls will negoti‐
237       ate TLS immediately after the connection has taken  place,  before  any
238       SMTP  commands  are  sent or received.  Encrypted data is labelled with
239       `(tls-encrypted)' and `(tls-decrypted)' when viewing the SMTP  transac‐
240       tion  with  the  -snoop  switch;  see  the post man page description of
241       -snoop for its other features.  The  -notls  switch  will  disable  all
242       attempts to negotiate TLS.
243
244       If  port  465  is  specified and none of the TLS switches were enabled,
245       -initialtls will be implied if TLS support  was  compiled  in.   Though
246       port 465 for SMTPS (SMTP over SSL) was deregistered by IANA in 1998, it
247       is still used for that service.
248
249       When using TLS the default is to verify the remote certificate and Sub‐
250       jectName against the local trusted certificate store.  This can be con‐
251       trolled by  the  -certverify  and  -nocertverify  switches.   See  your
252       OpenSSL documentation for more information on certificate verification.
253
254       The  files  specified  by  the profile entry “Aliasfile:” and any addi‐
255       tional alias files given by the -alias aliasfile switch  will  be  read
256       (more  than  one  file,  each  preceded  by -alias, can be named).  See
257       mh-alias(5) for more information.
258
259   Selection based on sender address: sendfrom
260       One or more sendfrom profile components can be used to  select  a  mail
261       server  address, mail server port, or any other switch that can be sup‐
262       plied to post.  It works by first looking at  the  sender  address  and
263       domain  name  in  the message draft, as described below.  It then looks
264       for a corresponding profile entry, which contains  the  post  switches.
265       To enable, add profile entries of the form:
266
267            sendfrom-address/domain name: post switches
268
269       The  email address is extracted from the Envelope-From:  header, if not
270       blank, the Sender: header, or the From:  header  line  in  the  message
271       draft.   Multiple  profile  entries,  with different email addresses or
272       domain names, are supported.  This allows different switches  to  post,
273       such  as  -user, to be associated with different email addresses.  If a
274       domain name is used, it matches all users in that domain.
275
276       Here is an example profile entry using OAuth for an account  hosted  by
277       gmail:
278
279            sendfrom-gmail_address@example.com: -sasl -saslmech xoauth2
280                 -authservice gmail -tls -server smtp.gmail.com
281                 -user gmail_login@example.com
282
283       (Indentation  indicates a continued line, as supported in MH profiles.)
284       The username need not be the same as  the  sender  address,  which  was
285       extracted from the appropriate header line as noted above.
286
287       Here are example profile entries that use an nmh credentials file:
288
289            credentials: file:nmhcreds
290            sendfrom-sendgrid_address@example.com: -sasl -tls
291                 -server smtp.sendgrid.net
292            sendfrom-outbound.att.net: -sasl -initialtls
293                 -server outbound.att.net -port 465
294            sendfrom-fastmail.com: -initialtls -sasl -saslmech LOGIN
295                 -server smtps-proxy.messagingengine.com -port 80
296
297       where  nmhcreds  is  in the user's nmh directory (from the Path profile
298       component) and contains:
299
300            machine smtp.sendgrid.net
301                 login sendgrid_login@example.com
302                 password ********
303            machine outbound.att.net
304                 login att_login@example.com
305                 password ********
306            machine smtps-proxy.messagingengine.com
307                 login fastmail_login@example.com
308                 password ********
309
310       For more information on authentication to mail servers, see  the  mhlo‐
311       gin(1)  man  page  for  OAuth  services, and mh-profile(5) man page for
312       login credentials.
313

FILES

315       $HOME/.mh_profile          The user profile
316

PROFILE COMPONENTS

318       Path:                To determine the user's nmh directory
319       Draft-Folder:        To find the default draft-folder
320       Aliasfile:           For a default alias file
321       Signature:           To determine the user's mail signature
322       mailproc:            Program to post failure notices
323       postproc:            Program to post the message
324       sendfrom-address:    Switches to post for sender address
325       sendfrom-domain:     Switches to post for sender domain name
326

SEE ALSO

328       comp(1), dist(1), file(1), forw(1), mhbuild(1), mhparam(1), mhlogin(1),
329       refile(1),  repl(1),  whatnow(1),  mh-alias(5),  mh-profile(5), mh-tai‐
330       lor(5), post(8)
331

DEFAULTS

333       `file' defaults to <mh-dir>/draft
334       `-alias' defaults to /etc/nmh/MailAliases
335       `-nodraftfolder'
336       `-nofilter'
337       `-format'
338       `-forward'
339       `-nomime'
340       `-nomsgid'
341       `-messageid localname'
342       `-nopush'
343       `-noverbose'
344       `-nowatch'
345       `-width 72'
346       `-certverify'
347

CONTEXT

349       None
350

BUGS

352       Under some configurations, it is  not  possible  to  monitor  the  mail
353       delivery transaction; -watch is a no-op on those systems.
354
355       Using -split 0 doesn't work correctly.
356
357
358
359nmh-1.7.1                         2017-05-11                           SEND(1)
Impressum