4 .TH MHSTORE %manext1% "%nmhdate%" MH.6.8 [%nmhversion%]
6 mhstore \- store contents of MIME messages into files
21 .RB [ \-auto " | " \-noauto ]
26 .RB [ \-check " | " \-nocheck ]
33 command allows you to store the contents of a
34 collection of MIME (multi-media) messages into files or other
38 manipulates multi-media messages as specified in
39 RFC\-2045 thru RFC\-2049.
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
49 switches, you may limit the scope of
52 subparts (of a multipart content) and/or particular content types.
60 file as the source message, rather than a message from a folder.
61 If you specify this file as \*(lq-\*(rq, then
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
70 be in mail drop format (to convert a file in mail drop format to
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
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
87 switch will not prevent
88 the content from being acted upon.
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.
94 A list of commonly used contents is briefly reproduced here:
102 multipart mixed, alternative, digest, parallel
103 message rfc822, partial, external-body
104 application octet-stream, postscript
111 A legal MIME message must contain a subtype specification.
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
119 a multipart content (of any subtype listed above) is always acted
120 upon. Further note that if the
122 switch is used, and it is
123 desirable to act on a message/external-body content, then the
125 switch must be used twice: once for message/external-body
126 and once for the content externally referenced.
127 .SS "Checking the Contents"
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
137 verify the integrity of the content.
138 .SS "Storing the Contents"
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
151 If this entry isn't present,
152 the current working directory is used.
156 switch is given, then
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
174 switch is not given (or is being ignored for security
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,
181 will look for an entry of
185 mhstore-store-<type>/<subtype>
188 to determine the formatting string. If this isn't found,
190 will look for an entry of the form:
196 to determine the formatting string.
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
203 If the formatting string consists solely of a \*(lq-\*(rq character,
204 then the content is sent to the standard output.
206 If the formatting string starts with a '|', then the display string
207 will represent a command for
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,
213 will change to the appropriate directory, and any
214 escapes (given below) in the display string will be expanded.
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. Note that if \*(lqnmh-storage\*(rq
222 is not an absolute path, it will be relative to the folder that
223 contains the message(s).
225 A command or pathname formatting string may contain the following
226 escapes. If the content isn't part of a multipart (of any subtype
227 listed above) content, the p-escapes are ignored.
232 %a Parameters from Content-type (only valid with command)
233 %m Insert message number
234 %P Insert part number with leading dot
235 %p Insert part number without leading dot
236 %t Insert content type
237 %s Insert content subtype
238 %% Insert character %
242 If no formatting string is found,
245 if the content is application/octet-stream with parameter
246 \*(lqtype=tar\*(rq. If so,
248 will choose an appropriate
249 filename. If the content is not application/octet-stream, then
251 will check to see if the content is a message. If
254 will use the value \*(lq+\*(rq. As a last resort,
256 will use the value \*(lq%m%P.%s\*(rq.
258 Example profile entries might be:
262 mhstore-store-text: %m%P.txt
263 mhstore-store-text: +inbox
264 mhstore-store-message/partial: +
265 mhstore-store-audio/basic: | raw2audio -e ulaw -s 8000 -c 1 > %m%P.au
266 mhstore-store-image/jpeg: %m%P.jpg
267 mhstore-store-application/PostScript: %m%P.ps
271 .SS "Reassembling Messages of Type message/partial"
273 is also able to reassemble messages that have been
274 split into multiple messages of type \*(lqmessage/partial\*(rq.
276 When asked to store a content containing a partial message,
278 will try to locate all of the portions and combine
279 them accordingly. The default is to store the combined parts as
280 a new message in the current folder, although this can be changed
281 using formatting strings as discussed above. Thus, if someone has
282 sent you a message in several parts (such as the output from
284 you can easily reassemble them all into a single
285 message in the following fashion:
290 msg part type/subtype size description
291 5 message/partial 47K part 1 of 4
292 6 message/partial 47K part 2 of 4
293 7 message/partial 47K part 3 of 4
294 8 message/partial 18K part 4 of 4
296 reassembling partials 5,6,7,8 to folder inbox as message 9
298 msg part type/subtype size description
299 9 application/octet-stream 118K
300 (extract with uncompress | tar xvpf -)
306 This will store exactly one message, containing the sum of the
307 parts. It doesn't matter whether the partials are specified in
310 will sort the partials, so that they
311 are combined in the correct order. But if
314 locate every partial necessary to reassemble the message, it will
322 will automatically do the extraction for you:
327 msg part type/subtype size description
328 5 message/partial 47K part 1 of 4
329 6 message/partial 47K part 2 of 4
330 7 message/partial 47K part 3 of 4
331 8 message/partial 18K part 4 of 4
333 reassembling partials 5,6,7,8 to folder inbox as message 9
335 msg part type/subtype size description
336 9 application/octet-stream 118K
337 (extract with uncompress | tar xvpf -)
341 -- tar listing appears here as files are extracted
347 listing is generated, the files are extracted.
348 A prudent user will never put
351 The correct procedure is to first use
353 to find out what will be extracted. Then
357 to perform the extraction.
358 .SS "External Access"
359 For contents of type message/external-body,
360 \fImhstore\fR supports these access-types:
373 For the \*(lqanon-ftp\*(rq and \*(lqftp\*(rq access types,
375 will look for the \*(lqnmh-access-ftp\*(rq
379 nmh-access-ftp: myftp.sh
382 to determine the pathname of a program to perform the FTP retrieval.
383 This program is invoked with these arguments:
387 domain name of FTP-site
393 \*(lqascii\*(rq or \*(lqbinary\*(rq
397 The program should terminate with an exit status of zero if the
398 retrieval is successful, and a non-zero exit status otherwise.
399 .SS "The Content Cache"
402 encounters an external content containing a
403 \*(lqContent-ID:\*(rq field, and if the content allows caching, then
404 depending on the caching behavior of
406 the content might be read from or written to a cache.
408 The caching behavior of
410 is controlled with the
414 switches, which define the policy for reading from,
415 and writing to, the cache, respectively. One of four policies may be
416 specified: \*(lqpublic\*(rq, indicating that
419 of a publically-accessible content cache; \*(lqprivate\*(rq, indicating
422 should make use of the user's private content cache;
423 \*(lqnever\*(rq, indicating that
425 should never make use of
426 caching; and, \*(lqask\*(rq, indicating that
430 There are two directories where contents may be cached: the profile entry
431 \*(lqnmh-cache\*(rq names a directory containing world-readable contents, and,
432 the profile entry \*(lqnmh-private-cache\*(rq names a directory containing
433 private contents. The former should be an absolute (rooted) directory
442 might be used if you didn't care that the cache got wiped after each
443 reboot of the system. The private chace is interpreted relative to the user's
444 mail storage, if not rooted, e.g.,
447 nmh-private-cache: .cache
450 (which is the default value).
451 .SS "User Environment"
452 Because the display environment in which
454 operates may vary for
457 will look for the environment variable
459 If present, this specifies the name of an additional
460 user profile which should be read. Hence, when a user logs in on a
461 particular machine, this environment variable should be set to
462 refer to a file containing definitions useful for that machine.
465 will attempt to consult one other additional
469 %etcdir%/mhn.defaults
472 which is created automatically during
479 .ta \w'%etcdir%/ExtraBigFileName 'u
480 ^$HOME/.mmh/profile~^The user profile
481 ^$MHSTORE~^Additional profile entries
482 ^%etcdir%/mhn.defaults~^System default MIME profile entries
485 .SH "PROFILE COMPONENTS"
489 .ta \w'ExtraBigProfileName 'u
490 ^Path:~^To determine the user's mail storage
491 ^Current\-Folder:~^To find the default current folder
492 ^nmh-access-ftp:~^Program to retrieve contents via FTP
493 ^nmh-cache~^Public directory to store cached external contents
494 ^nmh-private-cache~^Personal directory to store cached external contents
495 ^nmh-storage~^Directory to store contents
496 ^mhstore-store-<type>*~^Template for storing contents
500 mhbuild(1), mhlist(1), mhshow(1), sendfiles(1)
504 .RB ` +folder "' defaults to the current folder"
505 .RB ` msgs "' defaults to cur"
508 .RB ` \-rcache \ ask'
509 .RB ` \-wcache \ ask'
512 If a folder is given, it will become the current folder. The last
513 message selected will become the current message.
516 Partial messages contained within a multipart content are not reassembled.
projects / mmh / blob