1SEND(1)                            [nmh-1.3]                           SEND(1)
2
3
4

NAME

6       send - send a message
7

SYNOPSIS

9       send [-alias aliasfile] [-draft] [-draftfolder +folder] [-draftmessage
10            msg] [-nodraftfolder] [-filter filterfile] [-nofilter] [-format |
11            -noformat] [-forward | -noforward] [-mime | -nomime] [-msgid |
12            -nomsgid] [-push | -nopush] [-split seconds] [-verbose | -nover‐
13            bose] [-watch | -nowatch] [-sasl] [-saslmech mechanism] [-user
14            username] [-width columns] [file ...]  [-version] [-help] [-attach
15            header-field-name] [-attachformat 0 | 1 | 2]
16

DESCRIPTION

18       Send  will cause each of the specified files to be delivered to each of
19       the destinations in the “To:”, “cc:”, “Bcc:”, “Dcc:”, and “Fcc:” fields
20       of  the message.  If send is re-distributing a message, as invoked from
21       dist, then the corresponding “Resent-xxx” fields are examined instead.
22
23       By default, send uses the program post to do the actual delivery of the
24       messages, although this can be changed by defining the postproc profile
25       component.  Most of the features attributed to send are  actually  per‐
26       formed by post.
27
28
29       If  a header-field-name is supplied using the -attach option, the draft
30       is scanned for a header whose field name matches the  supplied  header-
31       field-name.   The  draft  is converted to a MIME message if one or more
32       matches are found.  This conversion occurs before all other processing.
33
34       The first part of the MIME message is the draft body if that body  con‐
35       tains  any  non-blank  characters.  The body of each header field whose
36       name matches the header-field-name is interpreted as a file  name,  and
37       each file named is included as a separate part in the MIME message.
38
39       For  file names with dot suffixes, the context is scanned for a mhshow-
40       suffix- entry for that suffix.  The content-type for the part is  taken
41       from  that  context entry if a match is found.  If no match is found or
42       the file does not have a dot suffix, the content-type is text/plain  if
43       the  file contains only ASCII characters or application/octet-stream if
44       it contains characters outside of the ASCII range.
45
46       Each part contains a name attribute that is the last component  of  the
47       path  name.   A x-unix-mode attribute containing the file mode accompa‐
48       nies each part.  Finally, a description attribute is generated by  run‐
49       ning the file command on the file.
50
51       The  -attachformat  option  specifies the MIME header field formats:  a
52       value of 0, the default, includes the x-unix-mode  attribute  as  noted
53       above.  A value of 1 suppresses both that and the “Content-Description”
54       header, and adds a “Content-Disposition” header.  A value of 2 adds the
55       file  modification-date  parameter to the “Content-Disposition” header.
56       You can specify one value in your profile, and override it for individ‐
57       ual messages at the whatnow prompt.
58
59       Here  are  example  message  part headers for each of the -attachformat
60       values:
61
62       -attachformat 0:
63       Content-Type: text/plain; name="VERSION"; x-unix-mode="0644";
64            charset="us-ascii"
65       Content-Description: ASCII text
66
67       -attachformat 1:
68       Content-Type: text/plain; charset="us-ascii"
69       Content-Disposition: attachment; filename="VERSION"
70
71       -attachformat 2:
72       Content-Type: text/plain; charset="us-ascii"
73       Content-Disposition: attachment; filename="VERSION"; modification-date="Mon, 19 Dec 2005 22:39:51 -0600"
74
75       If -push is specified, send will detach itself from the user's terminal
76       and  perform  its  actions  in the background.  If push'd and the draft
77       can't be sent, then an error message will be sent (using the  mailproc)
78       back  to the user.  If -forward is given, then a copy of the draft will
79       be attached to this failure notice.  Using -push differs  from  putting
80       send  in  the  background because the output is trapped and analyzed by
81       nmh.
82
83       If -verbose is specified, send will indicate the interactions occurring
84       with  the  transport  system,  prior  to actual delivery.  If -watch is
85       specified send will monitor the delivery of  local  and  network  mail.
86       Hence,  by  specifying both switches, a large detail of information can
87       be gathered about each step of the message's entry into  the  transport
88       system.
89
90       The  -draftfolder +folder and -draftmessage msg switches invoke the nmh
91       draft folder facility.  This is an advanced (and  highly  useful)  fea‐
92       ture.  Consult the mh-draft(5) man page for more information.
93
94       If -split is specified, send will split the draft into one or more par‐
95       tial messages prior to sending.  This makes use of the MIME features in
96       nmh.  Note however that if send is invoked under dist, then this switch
97       is ignored -- it makes no sense to redistribute a message in this fash‐
98       ion.  Sometimes you want send to pause after posting a partial message.
99       This is usually the case when you are running sendmail  and  expect  to
100       generate  a  lot  of partial messages.  The argument to -split tells it
101       how long to pause between postings.
102
103       Send with no file argument will query whether the draft is the intended
104       file,  whereas  -draft will suppress this question.  Once the transport
105       system has successfully accepted custody of the message, the file  will
106       be  renamed with a leading comma, which allows it to be retrieved until
107       the next draft message is sent.  If there are errors in the  formatting
108       of  the  message, send will abort with a (hopefully) helpful error mes‐
109       sage.
110
111       If a “Bcc:” field is encountered, its addresses will be used for deliv‐
112       ery,  and  the  “Bcc:”  field  will be removed from the message sent to
113       sighted recipients.  The blind recipients will receive an entirely  new
114       message  with  a  minimal  set of headers.  Included in the body of the
115       message will be a copy of the message sent to the sighted recipients.
116
117       If a “Dcc:” field is encountered, its addresses will be used for deliv‐
118       ery,  and the “Dcc:” field will be removed from the message.  The blind
119       recipients will receive the same message sent to  the  sighted  recipi‐
120       ents.  *WARNING*  Recipients  listed  in  the  “Dcc:”  field receive no
121       explicit indication that they have received a “blind copy”.   This  can
122       cause  blind  recipients  to  inadvertently reply to all of the sighted
123       recipients of the original message,  revealing  that  they  received  a
124       blind  copy.  On the other hand, since a normal reply to a message sent
125       via a “Bcc:” field will generate a reply only  to  the  sender  of  the
126       original message, it takes extra effort in most mailers to reply to the
127       included message, and so  would  usually  only  be  done  deliberately,
128       rather than by accident.
129
130       If -filter filterfile is specified, then this copy is filtered (re-for‐
131       matted) by mhl prior to being sent to  the  blind  recipients.   Alter‐
132       nately,  if  you  specify the -mime switch, then send will use the MIME
133       rules for encapsulation.
134
135       Prior to  sending  the  message,  the  fields  “From: user@local”,  and
136       “Date: now”  will  be  appended  to the headers in the message.  If the
137       environment variable $SIGNATURE is set, then its value is used as  your
138       personal  name  when  constructing the “From:” line of the message.  If
139       this environment variable is not set, then send will consult  the  pro‐
140       file  entry  “Signature” for this information.  If -msgid is specified,
141       then a “Message-ID:” field will also be added to the message.
142
143       If send is re-distributing a  message  (when  invoked  by  dist),  then
144       “Resent-”  will be prepended to each of these fields: “From:”, “Date:”,
145       and “Message-ID:”.  If the message already contains  a  “From:”  field,
146       then  a  “Sender: user@local” field will be added as well.  (An already
147       existing “Sender:” field is an error!)
148
149       By using the -format switch, each of the entries in the “To:” and “cc:”
150       fields  will be replaced with “standard” format entries.  This standard
151       format is designed to be usable by all of the message handlers  on  the
152       various systems around the Internet.  If -noformat is given, then head‐
153       ers are output exactly as they appear in the message draft.
154
155       If an “Fcc: folder” is encountered, the message will be copied  to  the
156       specified  folder  for the sender in the format in which it will appear
157       to any non-Bcc receivers of the message.  That is,  it  will  have  the
158       appended  fields  and  field  reformatting.   The “Fcc:” fields will be
159       removed from all outgoing copies of the message.
160
161       By using the -width columns switch, the user can direct send as to  how
162       long it should make header lines containing addresses.
163
164       If  nmh  has  been  compiled  with  SASL support, the -sasl switch will
165       enable the use of SASL authentication with the SMTP MTA.  Depending  on
166       the SASL mechanism used, this may require an additional password prompt
167       from the user (but the “.netrc” file can be used to  store  this  pass‐
168       word).  -saslmech switch can be used to select a particular SASL mecha‐
169       nism, and the the -user switch can be used to  select  a  authorization
170       userid to provide to SASL other than the default.
171
172       Currently  SASL security layers are not supported for SMTP.  nmh's SMTP
173       SASL code will always negotiate an unencrypted connection.  This  means
174       that  while  the  SMTP  authentication can be encrypted, the subsequent
175       data stream can not.  This is in contrast to nmh's POP3  SASL  support,
176       where  encryption is supported for both the authentication and the data
177       stream.
178
179       The files specified by the profile entry  “Aliasfile:”  and  any  addi‐
180       tional  alias  files  given by the -alias aliasfile switch will be read
181       (more than one file, each preceded  by  -alias,  can  be  named).   See
182       mh-alias(5) for more information.
183
184

FILES

186       $HOME/.mh_profile          The user profile
187
188

PROFILE COMPONENTS

190       Path:                To determine the user's nmh directory
191       Draft-Folder:        To find the default draft-folder
192       Aliasfile:           For a default alias file
193       Signature:           To determine the user's mail signature
194       mailproc:            Program to post failure notices
195       postproc:            Program to post the message
196
197

SEE ALSO

199       comp(1), dist(1), forw(1), repl(1), mh-alias(5), post(8)
200
201

DEFAULTS

203       `file' defaults to <mh-dir>/draft
204       `-alias' defaults to /etc/nmh/MailAliases
205       `-nodraftfolder'
206       `-nofilter'
207       `-format'
208       `-forward'
209       `-nomime'
210       `-nomsgid'
211       `-nopush'
212       `-noverbose'
213       `-nowatch'
214       `-width 72'
215       `-attachformat 0'
216
217

CONTEXT

219       None
220
221

BUGS

223       Under  some  configurations,  it  is  not  possible to monitor the mail
224       delivery transaction; -watch is a no-op on those systems.
225
226       Using -split 0 doesn't work correctly.
227
228
229
230MH.6.8                            1 June 2008                          SEND(1)
Impressum