Provided by: mmh_0.4-2_amd64 
NAME
mhstore - store contents of MIME messages into files
SYNOPSIS
mhstore [+folder] [msgs] [-file file] [-part number] ... [-type content] ... [-auto |
-noauto] [-Version] [-help]
DESCRIPTION
The mhstore command allows you to store the contents of a collection of MIME (multi-media)
messages into files or other messages.
mhstore manipulates multi-media messages as specified in RFC-2045 thru RFC-2049.
By default, mhstore will store all the parts of each message. Each part will be store in
a separate file. The header fields of the message are not stored. By using the -part and
-type switches, you may limit the scope of mhstore to particular subparts (of a multipart
content) and/or particular content types.
The option -file file directs mhstore to use the specified file as the source message,
rather than a message from a folder. If you specify this file as `-', then mhstore will
accept the source message on the standard input. Note that the file, or input from
standard input should be a validly formatted message, just like any other mh message. It
should NOT be in mail drop format (to convert a file in mail drop format to a folder of mh
messages, see inc(1)).
A part specification consists of a series of numbers separated by dots. For example, in a
multipart content containing three parts, these would be named as 1, 2, and 3,
respectively. If part 2 was also a multipart content containing two parts, these would be
named as 2.1 and 2.2, respectively. Note that the -part switch is effective for only
messages containing a multipart content. If a message has some other kind of content, or
if the part is itself another multipart content, the -part switch will not prevent the
content from being acted upon.
A content specification consists of a content type and a subtype. The initial list of
`standard' content types and subtypes can be found in RFC-2046.
A list of commonly used contents is briefly reproduced here:
Type Subtypes
---- --------
text plain, enriched
multipart mixed, alternative, digest, parallel
message rfc822, partial, external-body
application octet-stream, postscript
image jpeg, gif, png
audio basic
video mpeg
A legal MIME message must contain a subtype specification.
To specify a content, regardless of its subtype, just use the name of the content, e.g.,
`audio'. To specify a specific subtype, separate the two with a slash, e.g.,
`audio/basic'. Note that regardless of the values given to the -type switch, a multipart
content (of any subtype listed above) is always acted upon.
Storing the Contents
The mhstore will store the contents of the named messages in `native' (decoded) format.
Two things must be determined: the directory to store the content, and the filenames.
By default (or if the -auto switch is given), mhstore uses filename information, contained
in the message, if available. (This information should be specified as the attribute
`name=filename' in the `Content-Type' header for the content you are storing.) Only the
basename of this filename is considered. If it begins with the character '.', '|', or
'!', or if it contains the character '%', automatic naming won't happen for security
reasons. (See below for the fall-back.)
Files are written in the directory given by the `nmh-storage' profile entry, e.g.,
nmh-storage: /tmp
(Note that `nmh-storage' is relative to the folder that contains the message.) If this
entry isn't present, the current working directory is used. Attachments will get stored
in either the `nmh-storage' or the current working directory – in no case elsewhere.
Existing files get silently overwritten.
If the -noauto switch is given (or a filename is being ignored for security reasons) then
mhstore will look in the user's profile for a `formatting string' to determine how the
different contents should be stored. First, mhstore will look for an entry of the form:
mhstore-store-<type>/<subtype>
to determine the formatting string. If this isn't found, mhstore will look for an entry
of the form:
mhstore-store-<type>
to determine the formatting string.
If the formatting string starts with a `+' character, then content is stored in the named
folder. A formatting string consisting solely of a `+' character is interpreted to be the
current folder.
If the formatting string consists solely of a `-' character, then the content is sent to
the standard output.
If the formatting string starts with a '|', then the display string will represent a
command for mhstore to execute which should ultimately store the content. The content
will be passed to the standard input of the command. Before the command is executed,
mhstore will change to the appropriate directory, and any escapes (given below) in the
display string will be expanded.
Otherwise the formatting string will represent a pathname in which to store the content.
If the formatting string starts with a '/', then the content will be stored in the full
path given, else the file name will be relative to either the value of `nmh-storage', if
set, or the current working directory. Existing files get silently overwritten.
A command or pathname formatting string may contain the following escapes. If the content
isn't part of a multipart (of any subtype listed above) content, the p-escapes are
ignored.
%a Parameters from Content-type (only valid with command)
%m Insert message number
%P Insert part number with leading dot
%p Insert part number without leading dot
%t Insert content type
%s Insert content subtype
%% Insert character %
If no formatting string is found, mhstore will check to see if the content is a message.
If so, mhstore will use the value `+'. As a last resort, mhstore will use the value
`%m%P.%s'.
Example profile entries might be:
mhstore-store-text: %m%P.txt
mhstore-store-text: +inbox
mhstore-store-message/partial: +
mhstore-store-audio/basic: | raw2audio -e ulaw -s 8000 -c 1 > %m%P.au
mhstore-store-image/jpeg: %m%P.jpg
mhstore-store-application/PostScript: %m%P.ps
Reassembling Messages of Type message/partial
mhstore is also able to reassemble messages that have been split into multiple messages of
type `message/partial'.
When asked to store a content containing a partial message, mhstore will try to locate all
of the portions and combine them accordingly. The default is to store the combined parts
as a new message in the current folder, although this can be changed using formatting
strings as discussed above. Thus, if someone has sent you a message in several parts
(such as the output from sendfiles), you can easily reassemble them all into a single
message in the following fashion:
% mhlist 5-8
msg part type/subtype size description
5 message/partial 47K part 1 of 4
6 message/partial 47K part 2 of 4
7 message/partial 47K part 3 of 4
8 message/partial 18K part 4 of 4
% mhstore 5-8
reassembling partials 5,6,7,8 to folder inbox as message 9
% mhlist 9
msg part type/subtype size description
9 application/octet-stream 118K
(extract with uncompress | tar xvpf -)
type=tar
conversions=compress
This will store exactly one message, containing the sum of the parts. It doesn't matter
whether the partials are specified in order, since mhstore will sort the partials, so that
they are combined in the correct order. But if mhstore can not locate every partial
necessary to reassemble the message, it will not store anything.
External Access
Mhstore does not automatically retrieve message/external-body parts (anymore), but prints
the relevant information to enable the user to retrieve the files manually.
User Environment
Because the display environment in which mhstore operates may vary for different machines,
mhstore will look for the environment variable $MHSTORE. If present, this specifies the
name of an additional user profile which should be read. Hence, when a user logs in on a
particular machine, this environment variable should be set to refer to a file containing
definitions useful for that machine. Finally, mhstore will attempt to consult one other
additional user profile, e.g.,
/etc/mmh/mhn.defaults
which is created automatically during mmh installation.
FILES
$HOME/.mmh/profile The user profile
$MHSTORE Additional profile entries
/etc/mmh/mhn.defaults System default MIME profile entries
PROFILE COMPONENTS
Path: To determine the user's mail storage
Current-Folder: To find the default current folder
nmh-storage Directory to store contents
mhstore-store-<type>*Template for storing contents
SEE ALSO
mhbuild(1), mhlist(1), show(1), sendfiles(1)
DEFAULTS
`+folder' defaults to the current folder
`msgs' defaults to the current message
`-auto'
CONTEXT
If a folder is given, it will become the current folder. The last message selected will
become the current message.
BUGS
Partial messages contained within a multipart content are not reassembled.
Existing files get silently overwritten.