Updated to reflect that all of the lists are on nongnu.org.
[mmh] / man / mhstore.man
1 .\"
2 .\" %nmhwarning%
3 .\"
4 .TH MHSTORE %manext1% "%nmhdate%" MH.6.8 [%nmhversion%]
5 .SH NAME
6 mhstore \- store contents of MIME messages into files
7 .SH SYNOPSIS
8 .HP 5
9 .na
10 .B mhstore
11 .RI [ +folder ]
12 .RI [ msgs ]
13 .RB [ \-file
14 .IR file ]
15 .RB [ \-part
16 .IR number ]
17 \&...
18 .RB [ \-type
19 .IR content ]
20 \&...
21 .RB [ \-auto " | " \-noauto ]
22 .RB [ \-verbose " | " \-noverbose ]
23 .RB [ \-rcache
24 .IR policy ]
25 .RB [ \-wcache
26 .IR policy ]
27 .RB [ \-check " | " \-nocheck ]
28 .RB [ \-version ]
29 .RB [ \-help ]
30 .ad
31 .SH DESCRIPTION
32 The
33 .B mhstore
34 command allows you to store the contents of a
35 collection of MIME (multi-media) messages into files or other
36 messages.
37 .PP
38 .B mhstore
39 manipulates multi-media messages as specified in
40 RFC\-2045 thru RFC\-2049.
41 .PP
42 By default,
43 .B mhstore
44 will store all the parts of each message.
45 Each part will be store in a separate file.  The header fields of
46 the message are not stored.  By using the
47 .B \-part
48 and
49 .B \-type
50 switches, you may limit the scope of
51 .B mhstore
52 to particular
53 subparts (of a multipart content) and/or particular content types.
54 .PP
55 The option
56 .B \-file
57 .I file
58 directs
59 .B mhstore
60 to use the specified
61 file as the source message, rather than a message from a folder.
62 If you specify this file as \*(lq-\*(rq, then
63 .B mhstore
64 will
65 accept the source message on the standard input.  Note that the
66 file, or input from standard input should be a validly formatted
67 message, just like any other
68 .B nmh
69 message.  It should
70 .B NOT
71 be in mail drop format (to convert a file in mail drop format to
72 a folder of
73 .B nmh
74 messages, see
75 .BR inc (1)).
76 .PP
77 A part specification consists of a series of numbers separated by
78 dots.  For example, in a multipart content containing three parts,
79 these would be named as 1, 2, and 3, respectively.  If part 2 was
80 also a multipart content containing two parts, these would be named
81 as 2.1 and 2.2, respectively.  Note that the
82 .B \-part
83 switch is
84 effective for only messages containing a multipart content.  If a
85 message has some other kind of content, or if the part is itself
86 another multipart content, the
87 .B \-part
88 switch will not prevent
89 the content from being acted upon.
90 .PP
91 A content specification consists of a content type and a subtype.
92 The initial list of \*(lqstandard\*(rq content types and subtypes
93 can be found in RFC\-2046.
94 .PP
95 A list of commonly used contents is briefly reproduced here:
96 .PP
97 .RS 5
98 .nf
99 .ta \w'application  'u
100 Type    Subtypes
101 ----    --------
102 text    plain, enriched
103 multipart       mixed, alternative, digest, parallel
104 message rfc822, partial, external-body
105 application     octet-stream, postscript
106 image   jpeg, gif, png
107 audio   basic
108 video   mpeg
109 .fi
110 .RE
111 .PP
112 A legal MIME message must contain a subtype specification.
113 .PP
114 To specify a content, regardless of its subtype, just use the name
115 of the content, e.g., \*(lqaudio\*(rq.  To specify a specific
116 subtype, separate the two with a slash, e.g., \*(lqaudio/basic\*(rq.
117 Note that regardless of the values given to the
118 .B \-type
119 switch,
120 a multipart content (of any subtype listed above) is always acted
121 upon.  Further note that if the
122 .B \-type
123 switch is used, and it is
124 desirable to act on a message/external-body content, then the
125 .B \-type
126 switch must be used twice: once for message/external-body
127 and once for the content externally referenced.
128 .SS "Checking the Contents"
129 The
130 .B \-check
131 switch tells
132 .B mhstore
133 to check each content for
134 an integrity checksum.  If a content has such a checksum (specified
135 as a Content-MD5 header field), then
136 .B mhstore
137 will attempt to
138 verify the integrity of the content.
139 .SS "Storing the Contents"
140 The
141 .B mhstore
142 will store the contents of the named messages in
143 \*(lqnative\*(rq (decoded) format.  Two things must be determined:
144 the directory to store the content, and the filenames.  Files are
145 written in the directory given by the \*(lqnmh-storage\*(rq profile
146 entry, e.g.,
147 .PP
148 .RS 5
149 nmh-storage: /tmp
150 .RE
151 .PP
152 If this entry isn't present,
153 the current working directory is used.
154 .PP
155 If the
156 .B \-auto
157 switch is given, then
158 .B mhstore
159 will check if
160 the message contains information indicating the filename that should
161 be used to store the content.  This information should be specified
162 as the attribute \*(lqname=filename\*(rq in the \*(lqContent-Type\*(rq header
163 for the content you are storing.  For security reasons, this filename
164 will be ignored if it begins with the character '/', '.', '|', or '!',
165 or if it contains the character '%'.  For the sake of security,
166 this switch is not the default, and it is recommended that you do
167 NOT put the
168 .B \-auto
169 switch in your
170 .I \&.mh\(ruprofile
171 file.
172 .PP
173 If the
174 .B \-auto
175 switch is not given (or is being ignored for security
176 reasons) then
177 .B mhstore
178 will look in the user's profile for a
179 \*(lqformatting string\*(rq to determine how the different contents
180 should be stored.  First,
181 .B mhstore
182 will look for an entry of
183 the form:
184 .PP
185 .RS 5
186 mhstore-store-<type>/<subtype>
187 .RE
188 .PP
189 to determine the formatting string.  If this isn't found,
190 .B mhstore
191 will look for an entry of the form:
192 .PP
193 .RS 5
194 mhstore-store-<type>
195 .RE
196 .PP
197 to determine the formatting string.
198 .PP
199 If the formatting string starts with a \*(lq+\*(rq character, then
200 content is stored in the named folder.  A formatting string consisting
201 solely of a \*(lq+\*(rq character is interpreted to be the current
202 folder.
203 .PP
204 If the formatting string consists solely of a \*(lq-\*(rq character,
205 then the content is sent to the standard output.
206 .PP
207 If the formatting string starts with a '|', then the display string
208 will represent a command for
209 .B mhstore
210 to execute which should
211 ultimately store the content.  The content will be passed to the
212 standard input of the command.  Before the command is executed,
213 .B mhstore
214 will change to the appropriate directory, and any
215 escapes (given below) in the display string will be expanded.
216 .PP
217 Otherwise the formatting string will represent a pathname in which
218 to store the content.  If the formatting string starts with a '/',
219 then the content will be stored in the full path given, else the
220 file name will be relative to the value of \*(lqnmh-storage\*(rq or
221 the current working directory.  Any escapes (given below) will be
222 expanded, except for the a-escape.
223 .PP
224 A command or pathname formatting string may contain the following
225 escapes.  If the content isn't part of a multipart (of any subtype
226 listed above) content, the p-escapes are ignored.
227 .PP
228 .RS 5
229 .nf
230 .ta \w'%P  'u
231 %a      Parameters from Content-type  (only valid with command)
232 %m      Insert message number
233 %P      Insert part number with leading dot
234 %p      Insert part number without leading dot
235 %t      Insert content type
236 %s      Insert content subtype
237 %%      Insert character %
238 .fi
239 .RE
240 .PP
241 If no formatting string is found,
242 .B mhstore
243 will check to see
244 if the content is application/octet-stream with parameter
245 \*(lqtype=tar\*(rq.  If so,
246 .B mhstore
247 will choose an appropriate
248 filename.  If the content is not application/octet-stream, then
249 .B mhstore
250 will check to see if the content is a message.  If
251 so,
252 .B mhstore
253 will use the value \*(lq+\*(rq.  As a last resort,
254 .B mhstore
255 will use the value \*(lq%m%P.%s\*(rq.
256 .PP
257 Example profile entries might be:
258 .PP
259 .RS 5
260 .nf
261 mhstore-store-text: %m%P.txt
262 mhstore-store-text: +inbox
263 mhstore-store-message/partial: +
264 mhstore-store-audio/basic: | raw2audio -e ulaw -s 8000 -c 1 > %m%P.au
265 mhstore-store-image/jpeg: %m%P.jpg
266 mhstore-store-application/PostScript: %m%P.ps
267 .fi
268 .RE
269 .PP
270 .SS "Reassembling Messages of Type message/partial"
271 .B mhstore
272 is also able to reassemble messages that have been
273 split into multiple messages of type \*(lqmessage/partial\*(rq.
274 .PP
275 When asked to store a content containing a partial message,
276 .B mhstore
277 will try to locate all of the portions and combine
278 them accordingly.  The default is to store the combined parts as
279 a new message in the current folder, although this can be changed
280 using formatting strings as discussed above.  Thus, if someone has
281 sent you a message in several parts (such as the output from
282 .BR sendfiles ),
283 you can easily reassemble them all into a single
284 message in the following fashion:
285 .PP
286 .RS 5
287 .nf
288 % mhlist 5-8
289  msg part  type/subtype             size description
290    5       message/partial           47K part 1 of 4
291    6       message/partial           47K part 2 of 4
292    7       message/partial           47K part 3 of 4
293    8       message/partial           18K part 4 of 4
294 % mhstore 5-8
295 reassembling partials 5,6,7,8 to folder inbox as message 9
296 % mhlist -verbose 9
297  msg part  type/subtype             size description
298    9       application/octet-stream 118K
299              (extract with uncompress | tar xvpf -)
300              type=tar
301              conversions=compress
302 .fi
303 .RE
304 .PP
305 This will store exactly one message, containing the sum of the
306 parts.  It doesn't matter whether the partials are specified in
307 order, since
308 .B mhstore
309 will sort the partials, so that they
310 are combined in the correct order.  But if
311 .B mhstore
312 can not
313 locate every partial necessary to reassemble the message, it will
314 not store anything.
315 .SS "External Access"
316 For contents of type message/external-body,
317 \fImhstore\fR supports these access-types:
318 .PP
319 .IP \(bu 4
320 afs
321 .IP \(bu 4
322 anon-ftp
323 .IP \(bu 4
324 ftp
325 .IP \(bu 4
326 local-file
327 .IP \(bu 4
328 mail-server
329 .PP
330 For the \*(lqanon-ftp\*(rq and \*(lqftp\*(rq access types,
331 .B mhstore
332 will look for the \*(lqnmh-access-ftp\*(rq
333 profile entry, e.g.,
334 .PP
335 .RS 5
336 nmh-access-ftp: myftp.sh
337 .RE
338 .PP
339 to determine the pathname of a program to perform the FTP retrieval.
340 This program is invoked with these arguments:
341 .PP
342 .RS 5
343 .nf
344 domain name of FTP-site
345 username
346 password
347 remote directory
348 remote filename
349 local filename
350 \*(lqascii\*(rq or \*(lqbinary\*(rq
351 .fi
352 .RE
353 .PP
354 The program should terminate with an exit status of zero if the
355 retrieval is successful, and a non-zero exit status otherwise.
356 .PP
357 If this entry is not provided, then
358 .B mhstore
359 will use a simple
360 built-in FTP client to perform the retrieval.
361 .SS "The Content Cache"
362 When
363 .B mhstore
364 encounters an external content containing a
365 \*(lqContent-ID:\*(rq field, and if the content allows caching, then
366 depending on the caching behavior of
367 .BR mhstore ,
368 the content might be read from or written to a cache.
369 .PP
370 The caching behavior of
371 .B mhstore
372 is controlled with the
373 .B \-rcache
374 and
375 .B \-wcache
376 switches, which define the policy for reading from,
377 and writing to, the cache, respectively.  One of four policies may be
378 specified: \*(lqpublic\*(rq, indicating that
379 .B mhstore
380 should make use
381 of a publically-accessible content cache; \*(lqprivate\*(rq, indicating
382 that
383 .B mhstore
384 should make use of the user's private content cache;
385 \*(lqnever\*(rq, indicating that
386 .B mhstore
387 should never make use of
388 caching; and, \*(lqask\*(rq, indicating that
389 .B mhstore
390 should ask the user.
391 .PP
392 There are two directories where contents may be cached: the profile entry
393 \*(lqnmh-cache\*(rq names a directory containing world-readable contents, and,
394 the profile entry \*(lqnmh-private-cache\*(rq names a directory containing
395 private contents.  The former should be an absolute (rooted) directory
396 name.
397 .PP
398 For example,
399 .PP
400 .RS 5
401 nmh-cache: /tmp
402 .RE
403 .PP
404 might be used if you didn't care that the cache got wiped after each
405 reboot of the system.  The latter is interpreted relative to the user's
406 nmh directory, if not rooted, e.g.,
407 .PP
408 .RS 5
409 nmh-private-cache: .cache
410 .RE
411 .PP
412 (which is the default value).
413 .SS "User Environment"
414 Because the display environment in which
415 .B mhstore
416 operates may vary for
417 different machines,
418 .B mhstore
419 will look for the environment variable
420 .BR $MHSTORE .
421 If present, this specifies the name of an additional
422 user profile which should be read.  Hence, when a user logs in on a
423 particular machine, this environment variable should be set to
424 refer to a file containing definitions useful for that machine.
425 Finally,
426 .B mhstore
427 will attempt to consult one other additional
428 user profile, e.g.,
429 .PP
430 .RS 5
431 %etcdir%/mhn.defaults
432 .RE
433 .PP
434 which is created automatically during
435 .B nmh
436 installation.
437
438 .SH FILES
439 .fc ^ ~
440 .nf
441 .ta \w'%etcdir%/ExtraBigFileName  'u
442 ^$HOME/\&.mh\(ruprofile~^The user profile
443 ^$MHSTORE~^Additional profile entries
444 ^%etcdir%/mhn.defaults~^System default MIME profile entries
445 .fi
446
447 .SH "PROFILE COMPONENTS"
448 .fc ^ ~
449 .nf
450 .ta 2.4i
451 .ta \w'ExtraBigProfileName  'u
452 ^Path:~^To determine the user's nmh directory
453 ^Current\-Folder:~^To find the default current folder
454 ^nmh-access-ftp:~^Program to retrieve contents via FTP
455 ^nmh-cache~^Public directory to store cached external contents
456 ^nmh-private-cache~^Personal directory to store cached external contents
457 ^nmh-storage~^Directory to store contents
458 ^mhstore-store-<type>*~^Template for storing contents
459 .fi
460
461 .SH "SEE ALSO"
462 mhbuild(1), mhlist(1), mhshow(1), sendfiles(1)
463
464 .SH DEFAULTS
465 .nf
466 .RB ` +folder "' defaults to the current folder"
467 .RB ` msgs "' defaults to cur"
468 .RB ` \-noauto '
469 .RB ` \-nocheck '
470 .RB ` \-rcache ask '
471 .RB ` \-wcache ask '
472 .RB ` \-noverbose '
473
474 .SH CONTEXT
475 If a folder is given, it will become the current folder.  The last
476 message selected will become the current message.
477
478 .SH BUGS
479 Partial messages contained within a multipart content are not reassembled.