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