1SEND(1) General Commands Manual SEND(1)
2
6 send - send an nmh message
7
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
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 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 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 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 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 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 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 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 Content-Type: text/plain; name="VERSION"; charset="us-ascii"
72 Content-Description: VERSION
73 Content-Disposition: attachment; filename="VERSION"
74 See mhbuild(1) for explanation of how the Content-Disposition value is
76 selected.
77 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 By using the -width columns switch, the user can direct send as to how
192 long it should make header lines containing addresses.
193 The mail transport system default is provided in /etc/nmh/mts.conf but
195 can be overridden here with the -mts switch.
196 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 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 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 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 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 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 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 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 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 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 sendfrom-address/domain name: post switches
268 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 Here is an example profile entry using OAuth for an account hosted by
277 gmail:
278 sendfrom-gmail_address@example.com: -sasl -saslmech xoauth2
280 -authservice gmail -tls -server smtp.gmail.com
281 -user gmail_login@example.com
282 (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 Here are example profile entries that use an nmh credentials file:
288 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 where nmhcreds is in the user's nmh directory (from the Path profile
298 component) and contains:
299 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 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
315 $HOME/.mh_profile The user profile
316
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
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
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
349 None
350
352 Under some configurations, it is not possible to monitor the mail
353 delivery transaction; -watch is a no-op on those systems.
354 Using -split 0 doesn't work correctly.
356nmh-1.7.1 2017-05-11 SEND(1)