mhstore - store contents of MIME messages into files
mhstore [+folder] [msgs] [-file file]
[-part number]... [-type content]...
[-auto] [-noauto] [-check] [-nocheck]
[-rcache policy] [-wcache policy]
[-verbose] [-noverbose] [-version] [-help]
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
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 mes-
sage 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 spec-
ify 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 nmh message.
It should NOT be in mail drop format (to convert a file in mail drop
format to a folder of nmh 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 mes-
sages 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:
text plain, enriched
multipart mixed, alternative, digest, parallel
message rfc822, partial, external-body
application octet-stream, postscript
image jpeg, gif, png
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. Further note that if the `-type'
switch is used, and it is desirable to act on a message/external-body
content, then the `-type' switch must be used twice: once for mes-
sage/external-body and once for the content externally referenced.
Checking the Contents
The `-check' switch tells mhstore to check each content for an
integrity checksum. If a content has such a checksum (specified as a
Content-MD5 header field), then mhstore will attempt to verify the
integrity of the content.
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. Files are written in the direc-
tory given by the nmh-storage profile entry, e.g.,
If this entry isn't present, the current working directory is used.
If the `-auto' switch is given, then mhstore will check if the message
contains information indicating the filename that should be used to
store the content. This information should be specified as the
attribute "name=filename" in the Content-Type header for the content
you are storing. For security reasons, this filename will be ignored
if it begins with the character '/', '.', '|', or this switch is not
the default, and it is recommended that you do NOT put the `-auto'
switch in your .mh_profile file.
If the `-auto' switch is not given (or 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:
to determine the formatting string. If this isn't found, mhstore will
look for an entry of the form:
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 the value of nmh-storage or the current working
directory. Any escapes (given below) will be expanded, except for the
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 con-
tent is application/octet-stream with parameter "type=tar". If so,
mhstore will choose an appropriate filename. If the content is not
application/octet-stream, then 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-audio/basic: | raw2audio -e ulaw -s 8000 -c 1 > %m%P.au
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 cur-
rent 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 -verbose 9
msg part type/subtype size description
9 application/octet-stream 118K
(extract with uncompress | tar xvpf -)
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 cor-
rect order. But if mhstore can not locate every partial necessary to
reassemble the message, it will not store anything.
For contents of type message/external-body, mhstore supports these
For the "anon-ftp" and "ftp" access types, mhstore will look for the
nmh-access-ftp profile entry, e.g.,
to determine the pathname of a program to perform the FTP retrieval.
This program is invoked with these arguments:
domain name of FTP-site
"ascii" or "binary"
The program should terminate with an exit status of zero if the
retrieval is successful, and a non-zero exit status otherwise.
If this entry is not provided, then mhstore will use a simple built-in
FTP client to perform the retrieval.
The Content Cache
When mhstore encounters an external content containing a "Content-ID:"
field, and if the content allows caching, then depending on the caching
behavior of mhstore, the content might be read from or written to a
The caching behavior of mhstore is controlled with the `-rcache' and
`-wcache' switches, which define the policy for reading from, and writ-
ing to, the cache, respectively. One of four policies may be speci-
fied: "public", indicating that mhstore should make use of a publi-
cally-accessible content cache; "private", indicating that mhstore
should make use of the user's private content cache; "never", indicat-
ing that mhstore should never make use of caching; and, "ask", indicat-
ing that mhstore should ask the user.
There are two directories where contents may be cached: the profile
entry nmh-cache names a directory containing world-readable contents,
and, the profile entry nmh-private-cache names a directory containing
private contents. The former should be an absolute (rooted) directory
name. For example,
might be used if you didn't care that the cache got wiped after each
reboot of the system. The latter is interpreted relative to the user's
nmh directory, if not rooted, e.g.,
(which is the default value).
Because the environment in which mhstore operates may vary for differ-
ent 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 machine, this environ-
ment 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.,
which is created automatically during nmh installation.
$HOME/.mh_profile The user profile
$MHSTORE Additional profile entries
/etc/nmh/mhn.defaults System default MIME profile entries
Path: To determine the user's nmh directory
Current-Folder: To find the default current folder
nmh-access-ftp: Program to retrieve contents via FTP
nmh-cache Public directory to store cached external contents
nmh-private-cache Personal directory to store cached external contents
nmh-storage Directory to store contents
mhstore-store-<type>*Template for storing contents
mhbuild(1), mhlist(1), mhshow(1), sendfiles(1)
Multipurpose Internet Mail Extensions (MIME) Part One:
Format of Internet Message Bodies,
Multipurpose Internet Mail Extensions (MIME) Part Two:
Multipurpose Internet Mail Extensions (MIME) Part Three:
Message Header Extensions for Non-ASCII Text,
Multipurpose Internet Mail Extensions (MIME) Part Four:
Multipurpose Internet Mail Extensions (MIME) Part Five:
Conformance Criteria and Examples.
`+folder' defaults to the current folder
`msgs' defaults to cur
If a folder is given, it will become the current folder. The last mes-
sage selected will become the current message.
Partial messages contained within a multipart content are not reassem-
[nmh-1.0.4] MH.6.8 MHSTORE(1)
Man(1) output converted with